Systems and methods for implementing scheduled release of digital content to connections including existing and future family members of a digitized family tree

Abstract

A digital content creation and sharing platform particularly effective for posthumous release of digital content by a subject user to friends and family, but also useable by deployed military members whose living or deceased status is unknown. Each user can populate a family tree with both existing and future (unborn / unknown) members, as selectable recipients of any content composed for future release, scheduled by date, age or life events (marriages, births, anniversaries, graduations, etc.). Family members can include dependent users, registered under their primary guardian's account, and for whom secondary guardians can be assigned for account continuity in the event of the primary guardian's passing or resignation. Dependent users are only publicly searchable by their guardian for protection of underaged users. Dependent users of appropriate age can ultimately be emancipated from their guardian's account, to become full fledged users, and carryover their existing family trees and content.

Description

[0001] SYSTEMS AND METHODS FOR IMPLEMENTING SCHEDULED RELEASE OF DIGITAL CONTENT TO CONNECTIONS INCLUDING EXISTING AND FUTURE FAMILY MEMBERS OF A DIGITIZED FAMILY TREE CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority benefit of U.S. Provisional Application No.

[0003] 63 / 771,801, filed March 14, 2025, the entirety of which is incorporated herein by reference. FIELD OF THE INVENTION

[0004] The present invention relates generally to computer-implemented systems and methods for creation and distribution of digital content to users of an online platform, and more particularly to such systems and methods particularly catered, though not necessarily limited exclusively, to posthumous distribution of stored digital content created during the lifespan of deceased users.

[0005] BACKGROUND

[0006] In prior patent literature, there have been several proposals for exploiting moder computer technology for the particular purpose of enabling the deceased to leave behind personalized messages to their loved ones after their passing. Despite these prior endeavours, and to the best of the Applicant’s knowledge, there has yet to be an overly successful commercial implementation of this concept. Applicant has designed, from the ground up, what is believed to be a superior implementation of this concept, embodied in an online content sharing platform which adds numerous posthumous content sharing functionalities and capabilities previously unseen heretofore, that are believed to render the invention both technologically improved over the prior art, and much more likely to appeal to the general public and provide an engaging and rewarding user experience.

[0007] SUMMARY OF THE INVENTION

[0008] According to a first aspect of the invention, there is provided a system for automated posthumous release of digital content created by a subject user prior to death for later consumption of said digital content by one or more intended recipients, said system comprising:

[0009] one or more computing devices communicable with other computing devices over one or more communications networks, and comprising thereamong:

[0010] one or more processors;

[0011] one or more non-transitory computer readable media having stored therein computer readable code executable by said one or more processors;

[0012] data storage in which said digital content is stored;

[0013] one or more databases for storing therein data concerning said subjectuser, said one or more intended recipients, and said digital content;

[0014] wherein said computer readable code is configured to, when executed, perform at least the following steps:

[0015] (a) store, in said one or more databases:

[0016] family tree data representative of a family tree of the subject user, one node of which is representative of the subject user, and other nodes of which are each individually representative of a respective existing or unborn family member of the subject user, and are each represented in said family tree data, at least in part, by reference to another member of said family tree and a relationship specifier that specifies a familial relationship between said existing or unborn family member and said other member of said family tree;

[0017] release-governing data for one or more scheduled releases of the digital content from the subject user to the one or more intended recipients, said release-governing data comprising:

[0018] for each one of the one or more scheduled releases, content identification data denoting identification of an entirety or subset of the digital content created by the subject user as subject content for said each one of the one or more scheduled releases;

[0019] for each one of the one or more scheduled releases, scheduling data indicative of an intended timing at which to trigger said one of the one or more scheduled releases; and

[0020] for each one of the one or more scheduled releases, recipient identification data indicative of at least one intended recipient for said each one of the one or more scheduled releases, among which the recipient identification data for at least one of the one or more scheduled releases comprises identification of at least one member of the family tree that has been designated, based on recipient selection input from the subject user, as said at least one recipient for said at least one of the scheduled releases; and

[0021] (b) for at least one of the one or more scheduled releases, and after recategorization of the subject user as a deceased user, release of the subject content of said at least one of the one or more scheduled releases both:

[0022] in a scheduled manner conditional on confirmed fulfillment of a conditional timing requirement dictated by the scheduling data of said at least one of the one or more scheduled releases; and

[0023] in a recipient-targeted manner specifically released to the at least one intended recipient identified by the recipient identification data of said at least one of the one or more scheduled releases.In some instances, the conditional timing requirement for at least one of the one or more scheduled releases may comprise a particular date on which said one of the one or more scheduled releases is to be released in automated fashion. The particular date may have been inputted by the subject user during assignment of the scheduling data, or system may have instead derived the particular date from a combination of user input of a particular age (of themself, or another user) that the system cross-references against user date-of-birth records in the database to convert the user-inputted age into a calendar date.

[0024] In the same or other instances, the release-governing data for at least one of the one or more scheduled releases, includes event data representative of at least one anticipated future life-event, passage of which denotes fulfillment of the conditional timing requirement that triggers release of the subject content of said one of the one or more scheduled releases.

[0025] In such instances, step (b) may comprise, for said one of the one or more scheduled releases, and before release of the subject content thereof, first receiving event confirming input data from another user indicative of passage of said anticipated future event, thereby denoting said confirmed fulfillment of the conditional timing requirement, and thereafter releasing the subject content of said subset of the one or more scheduled releases in said targeted manner.

[0026] According to a second aspect of the invention there is provided a computer-implemented method of implementing automated posthumous release of digital content created by a subject user prior to death for later consumption of said digital content by one or more intended recipients, said method comprising performance, by one or more computing devices communicable with other computing devices over one or more communications networks:

[0027] (a) storage in one or more databases of:

[0028] family tree data representative of family tree of the subject user, one node of which is representative of the subject user, and other nodes of which are each individually representative of a respective existing or unborn family member of the subject user, and are each represented in said family tree data, at least in part, by reference to another member of said family tree and a relationship specifier that specifies a familial relationship between said existing or unborn family member and said another member of said family tree;

[0029] release-governing data for one or more scheduled releases of the digital content from the subject user to the one or more intended recipients, said release-governing data comprising:

[0030] for each one of the one or more scheduled releases, content identification data denoting identification of an entirety or subset of the digital content createdby the subject user as subject content for said each one of the one or more scheduled releases;

[0031] for each one of the one or more scheduled releases, scheduling data indicative of an intended timing at which to trigger said one of the one or more scheduled releases; and

[0032] for each one of the one or more scheduled releases, recipient identification data indicative of at least one intended recipient for said each one of the one or more scheduled releases, among which the recipient identification data for at least one of the one or more scheduled releases comprises identification of at least one member of the family tree that has been designated, based on recipient selection input from the subject user, as said at least one recipient for said at least one of the scheduled releases; and

[0033] (b) monitoring for fulfillment of a conditional timing requirement dictated by the scheduling data of said at least one of the one or more scheduled releases to trigger release of the subject content thereof in a recipient-targeted manner specifically released to the at least one intended recipient identified by the recipient identification data of said at least one of the one or more scheduled releases.

[0034] Preferred implementations of the second aspect of the invention may be further characterized in equivalent manner to any one or more of the dependent claims of dependent relationship to the claim of equivalent relationship to the first aspect of the invention.

[0035] According to a third aspect of the invention, there is provided a system for automated posthumous release of digital content created or uploaded by a subject user prior to death for later consumption of said digital content by one or more intended recipients, said system comprising:

[0036] one or more computing devices communicable with other computing devices over one or more communications networks, and comprising thereamong:

[0037] one or more processors;

[0038] one or more non-transitory computer readable media having stored therein computer readable code executable by said one or more processors;

[0039] data storage in which said digital content is stored;

[0040] one or more databases for storing therein data concerning said subject user, said one or more intended recipients, and said digital content;

[0041] wherein said computer readable code is configured to, when executed, perform at least the following steps:

[0042] (a) store, in said one or more databases, timeline message data for posthumous communication of timeline-based messages composed by the subject user before death, saidtimeline message data comprising identification data denoting identification of subject content, from among the digital content created or uploaded by the subject user, for each one of said timeline-based messages, and recipient identification data indicative of at least one intended recipient for said each one of said timeline-based messages;

[0043] (b) present to the subject user, before death, a timeline plotting tool on which a series of said timeline-based messages are plotted for visualization to the subject user of anticipated posthumous timing of messages; and

[0044] (c) after recategorization of the subject user as a deceased user, release the timeline-based messages at chronological intervals over a timeline;

[0045] further characterized by at least one of the following:

[0046] (i) said one or more databases also have stored therein scheduled message data for posthumous communication of user-scheduled messages likewise composed by the subject user before death, said scheduled message data comprising additional identification data denoting identification of subject content, from among the digital content created or uploaded by the subject user, for each one of said scheduled messages, additional recipient identification data indicative of at least one intended recipient for said each one of said scheduled messages, and scheduling data indicative of user-intended timing at which to trigger said one of the one or more scheduled releases, and step (c) comprises releasing the timeline-based messages independently of the user-scheduled messages at timeline intervals;

[0047] (ii) presentation to the subject user, in step (b) after plotting at least a subset of the timeline-based messages, of a timeline visualization on which both of the timeline messages and the user-scheduled messages are viewable as a collection of uploaded messages slated for posthumous release, and from which editing access to at least a subset of said uploaded messages is accessible to the subject user for user-reconfiguration of said collection;

[0048] (iii) presentation to the subject user, in step (b) after plotting at least a subset of the timeline -based messages, a message editor through which a selected one or more of the timeline-based messages are convertible into another scheduled release by user-triggered assignment of newly assigned scheduling data to the selected one or more of the timeline-based messages and

[0049] (iv) calculation of the timeline intervals in dependent relation to a total uploaded quantity of said timeline messages and a currently assigned duration of the timeline.

[0050] According to a fourth aspect of the invention, there is provided a computer-implemented method of implementing automated posthumous release of digital content created by a subject user prior to death for later consumption of said digital content by one or moreintended recipients, said method comprising performance, by one or more computing devices communicable with other computing devices over one or more communications networks:

[0051] (a) storage in one or more databases of timeline message data for posthumous communication of timeline-based messages composed by the subject user before death, said timeline message data comprising identification data denoting identification of subject content, from among the digital content created or uploaded by the subject user, for each one of said timeline-based messages, and recipient identification data indicative of at least one intended recipient for said each one of said timeline-based messages; and

[0052] (b) presentation to the subject user, before death, of a timeline plotting tool on which a series of said timeline-based messages are plotted for visualization to the subject user of anticipated posthumous timing of messages; and

[0053] (c) after recategorization of the subject user as a deceased user, release the timeline-based messages at chronological intervals over a timeline;

[0054] further characterized by at least one of the following:

[0055] (i) further storage in said one or more databases of scheduled message data for posthumous communication of user-scheduled messages likewise composed by the subject user before death, said scheduled message data comprising additional identification data denoting identification of subject content, from among the digital content created or uploaded by the subject user, for each one of said scheduled messages, additional recipient identification data indicative of at least one intended recipient for said each one of said scheduled messages, and scheduling data indicative of user-intended timing at which to trigger said one of the one or more scheduled releases, and step (c) comprises releasing the timeline-based messages independently of the user-scheduled messages at timeline intervals;

[0056] (ii) further presentation to the subject user, in step (b) after plotting at least a subset of the timeline-based messages, of a timeline visualizer on which both of the timeline messages and the user-scheduled messages are viewable as a collection of uploaded messages slated for posthumous release, and from which editing access to at least a subset of said uploaded messages is accessible to the subject user for user-reconfiguration of said collection;

[0057] (iii) further presentation to the subject user, in step (b) after plotting at least a subset of the timeline-based messages, a message editor through which a selected one or more of the timeline-based messages are convertible into another scheduled release by user-triggered assignment of newly assigned scheduling data to the selected one or more of the timeline-based messages; and

[0058] (iv) calculation of the timeline intervals in dependent relation to a total uploadedquantity of said timeline messages and a currently assigned duration of the timeline.

[0059] Preferred implementations of the fourth aspect of the invention may be further characterized in equivalent manner to any one or more of the dependent claims of dependent relationship to the claim of equivalent relationship to the third aspect of the invention.

[0060] Other inventive aspects of the system, and various optional, preferred, advantageous and beneficial features, functionalities and implementations thereof, will become apparent from the following detailed description of preferred embodiments.

[0061] BRIEF DESCRIPTION OF THE DRAWINGS

[0062] One or more preferred but non-limiting embodiments of the invention are described in detail herein below with reference accompanying drawings in which:

[0063] Figure 1 is a system diagram illustrating system componentry, modules and basic data flow in an inventive computer-implemented system for creation, storage and posthumous release of digital content created by living users of the system for release to user-designated family members and other personal connections after death of those living users.

[0064] Figure 2A illustrates a first subset of database tables from the database of the Figure 1 system, among which there are identified persons of both registered status (users) and unregistered status (non-users), and also interpersonal connections between such persons.

[0065] Figure 2B illustrates a second subset of database tables from the database of the Figure 1 system, notably among which there is stored family tree data by which familial relationships between the persons are identified.

[0066] Figure 2C illustrates a third subset of database tables from the database of the Figure 1 system, notably among which there is stored identification of digital content created by registered users, and data governing the release of such digital content to designated recipients after death of such registered users.

[0067] Figures 3A through 3X are screenshots of different interactive screens in a graphical user interface (GUI) through which a user navigates the system of Figure 1 to add currently existing family members and future unborn children to a digital family tree as candidate recipients for posthumously released digital content, and by which the user can visually browse and interact with the family tree and add dependent users under a shared account.

[0068] Figure 4 is a flowchart illustrating steps of an interactive process between a user and the system via the aforementioned GUI in order to populate the digital family tree of the user with currently existing family members, whether or not those family members are registered users of the system.

[0069] Figure 5 is a flowchart illustrating steps of an interactive process between a userand the system via the aforementioned GUI in order to populate the digital family tree of the user with future unborn children.

[0070] Figure 5A is a continuation of the Figure 5 flowchart, showing subsequent steps relating to those in the preceding figure, but typically performed separately at a later stage in time.

[0071] Figure 6 is a flowchart illustrating steps of an interactive process between a user and the system via the aforementioned GUI in order to add a dependent to the user’s account.

[0072] Figures 7 A through 70 are screenshots of different interactive screens in the graphical user interface through which the user navigates system of Figure 1 to create and upload digital content and schedule automated posthumous release thereof to the designated recipients.

[0073] Figure 8 is a flowchart illustrating steps of an interactive process between the system and two users that initially share an account and are related as guardian and dependent (e.g. parent and child), which process is operable to effectively emancipate the dependent from the guardian’s account.

[0074] Figure 8A is a continuation of the Figure 8 flowchart.

[0075] DETAIUED DESCRIPTION

[0076] Figure 1 illustrates one preferred but non-limiting embodiment of a system 10 of the present invention, whose various functionalities and capabilities include automated posthumous release of digital content created or uploaded by a subject user for later consumption of said digital content by one or more user-designated recipients. The system is implemented as an online platform comprising a plurality of computing devices communicable over one or more communication networks, and comprising thereamong a plurality of processors, a plurality of non-transitory computer readable memories having stored therein computer readable code executable by said processors, data storage for storing of said digital content, and one or more databases for storing therein user data and recipient data concerning said subject user and said one or more intended recipients, respectively, and also release-governing data for implementing one or more scheduled releases of the digital content to said one or more intended recipients, on behalf of said user, after death of said user.

[0077] In the illustrated embodiment of Figure 1, the computing devices include one or more user devices 12, each typically embodied as a smartphone, tablet computer, laptop computer, desktop computer, etc. on which a user can interact with the system via either a dedicated mobile application 14A run on that user device or a web application 14B run through a web browser application of that user device 12. The mobile or web application 14A, 14B (referred to generically as the user application 14), displays a graphical user interface (GUI) ona screen of the user device, select screenshots from one embodiment of which are shown in Figures 3 and 7 of the present application in demonstration of particularly novel and inventive functionalities of the present invention, though the particular onscreen aesthetic and layout of interactive onscreen elements may vary from those particularly illustrated, without detraction from the general functionality described and claimed herein.

[0078] Still referring to the Figure 1 example of one workable implementation of the inventive system 10, this example employs a client server architecture in which the user devices are the client devices, which communicate with one or more servers 16, 18, 20 over a communications network, most typically the internet. Among these servers 16, 18, 20 are hosted one or more backend applications 22, 24A, 24B, 24C, 24D, 24E, typically accessed by the client devices indirectly through one or more intermediaries, for example one or more API gateways, of which the illustrated embodiment has separate API gateways 26A, 26B hosted by an intermediary server 16 for respectively handling API calls from the mobile and web applications 14A, 14B of the user devices 12, though this need not necessarily be the case in other embodiments. In the illustrated example, the backend applications include a dedicated backend application 22 responsible for primary functionalities specific to the inventive aspects of the system 10, and a number of third-party services 24A, 24B, 24C, 24D, 24E running on other servers 20 and exploited by the backend application 22 for needs thereof that are likewise shared by other unrelated systems.

[0079] It will be appreciated that reference herein to any server may refer to either a physical server or a virtual cloud server, unless stated otherwise, and that any reference to a server in the singular also encompasses the possibility of employing multiple servers in place thereof. It will also be appreciated that that while the illustrated embodiment employs a serverclient architecture, the various processes and functionalities disclosed herein could alternatively be implemented in similar or comparable fashion in a decentralized or peer-to-peer architecture, which alternative implementations are within the scope of the present invention.

[0080] In the illustrated example, the third party services include a digital content creation service 24A (e.g. Amazon IVS (Interactive Video Service) for generation of digital video and audio content, data storage service 24B (e.g. Amazon S3 cloud storage) for storage of such digital video and audio content, a payment gateway 24C (e.g. Stripe) for handling user payment of subscription fees and other financial transactions, and one or more notification services, for example including an email service 24D (e.g. SendGrid) for sending email notifications, a text message service (not shown) and an app notification service 24E (e.g. FireBase) for sending push notifications to the client applications (in alternative to integrationof push notification functionality directly into the backend application 20, which may instead be implemented in other embodiments).

[0081] As illustrated, the backend application 22 may typically be embodied in a plurality of software modules specialized to particular tasks to be executed by the backend application 22 in fulfillment of the various functionalities of the system 10 described herein, which may include a video and audio module 26A for communicating with the digital content creation service 24A and data storage service 24B during user-creation / upload and storage of digital content through the GUI of the client app 14, a payment module 26B for communicating with the payment gateway 24C to effect funding of user accounts and payment of subscription fees therefrom, and optionally other financial transactions, for example between user accounts, a notification module 26D for instructing the email, text message and app notification services when emails, text messages and app notifications are to be sent by the backend application 22 for any purposes contemplated herein, a timeline module 26E responsible for handling appropriately timed release of a user’s user-created digital content after death of that user in accordance with scheduled times, confirmed events, and / or calculated timeline message frequency in relation to which that user had designated such release of the digital content, and a user module 26F for managing user data concerning users of the system and their personal connections, both familial and otherwise.

[0082] The system includes one or more databases 28A, 28B accessible to the backend application 22 for the purpose of storing all the user and recipient data and release-governing data, and any other operational data necessary to the various functionalities attributed to the system herein, aside from the user-created digital content that is stored separately of the database(s) in the illustrated example by the third party data storage service 24B. In the illustrated example, a master-slave database replication architecture is used, where the backend application 20 writes to one or more master or primary databases 28A, from which the data content thereof is copied and synchronized to one or more slave or secondary database 28B. For brevity, the singular grammatical form of database 28 is primarily used herein, but whose meaning will be understood to encompass multiple databases within the scope of this singular form.

[0083] Any and all method, processes, tasks or steps referred to herein are performed by processor execution of machine-readable code (executable statements and instructions) stored in one or more of the non-transitory computer readable media embodied among the one or more computing devices, except where stated otherwise, for example in the case of steps explicitly attributed to one or more users of the system. While the interest of a thorough disclosure, somesteps are described in a manner attributed to a particular subset of those plurality of computing devices in the interest of a thorough disclosure representative of preferred or prototyped embodiments, it will be appreciated that the system architecture the quantity of computing devices embodied therein, and the distribution of methods, processes, tasks or steps among those computing devices may be varied in any number of ways, all within the scope of the invention claimed herein.

[0084] Figures 2A to 2C illustrate one workable example of database schema that may be employed to implement the various functionalities of the system disclosed and claimed herein. The database tables in the illustrated example include a users table 30 for storing user data concerning registered users of the system, a persons table 32 for storing personal data on all persons documented in the system, including both registered users of the system and unregistered persons, a connections table 34 for storing details of interpersonal connections (including both familial relationships and friendships) between registered users, and also between registered users and unregistered persons, a family member table 36 for storing details of familial relationships between registered users, and also between registered users and unregistered persons, a member-type table 38 for storing details of different family member types (relationship types) usable in the family member table, a blocked-user table 40 for storing details of blocked users that have been blocked from interacting with other users at the request of those other users, a channel followers table 42 for store details of which users are following content channels of other users, a digital content table 44 for storing details of digital content created or uploaded by users, including release-governing data that governs when and to whom such digital content is released posthumously after death of the subject user that created / uploaded each such piece of digital content, and a user-subscription table 46 containing subscription or account data concerning each user’s registered account in the system. Followers of a content channel will have their respective feeds populated with publicly designated posts by the subject users of such followed content channels.

[0085] A significant distinction of the present invention over prior art systems for release of posthumous messages or content to the bereaved is the integration into the inventive system disclosed herein of a family tree functionality by which family members of the subject user are mapped relative thereto by familial relationship, and even more uniquely by enabling useraddition of as yet unborn future family members to such family tree so that the subject user can designate future release of created / uploaded digital content to such future family members who are not yet bom at the time that the digital content is created / uploaded, and may remain as yet unborn at the time of the subject user’s death. Figure 3 A illustrates a screenshot of a scrollablefamily tree visualizer 48 in the GUI of the mobile application, an equivalent of which is likewise implemented in the web application, and need not be duplicated in the figures (as is also true of each other GUI screenshot illustrated and described herein). The family tree visualizer shows a subject user their particular family tree, each of node of which is visually represented on screen, at least in part, either by a photographic likeness 50 of any actual existing family member of the family tree, especially for such family members that are registered users of the systems having stored profile pictures (e.g. stored by the data storage service 24B) that may be used for such purpose, or by a placeholder avatar 52 for unborn future family members for whom no photographic likeness yet exists. Each photographic likeness of an existing family member is preferably accompanied by the name of the existing family member, and each photographic likeness or avatar is preferably also accompanied by display of the familial relationship of the existing or unborn family member to the subject user. Instead of a proper name, a placeholder such as “unborn” or “TBD” may be displayed for each unborn family member at the respective node of the family tree visualizer.

[0086] With continued reference to Figure 3A, for any nodes in the visualized family tree for which the family member of that node has been designated by the subject user as a recipient one or more scheduled posthumous releases of digital content from the subject user, there may be shown a content release recipient identifier 54 at said visualized node, which may be in the form of a numerical identifier, the numerical value of which specifies the number of such scheduled posthumous releases for which that family member has been designated as a recipient. This way, at a quick glance of the family tree visualizer 48, the subject user can easily judge which family members have been appropriately addressed, overly addressed or under addressed in the subject user’s posthumous content release planning efforts to date. A home node 56 of the visualized family tree is one assigned to the subject user whose family tree is displayed, and may be characterized by an enlarged photographic likeness 5A (e.g. profile picture) of larger scale than those of the other nodes in the tree, whereby the subject user can more easily locate this home node 56 during navigation of the scrollable family tree. The home node 56 may be outfitted with a menu button 58 for bringing up the family management menu 60 that is shown in Figure 3B, and discussed in more detail further below. The family tree visualizer 48 may be navigated to from one or more other screens using a profile picture button 59 displayed in a header of some screens, as shown in Figure 3H.

[0087] The family tree visualizer maps the family tree generationally, in top-down relationship from oldest generation to youngest generation, at least in the illustrated example, though other mapping directionality (e.g. left to right) may alternatively be employed, using thedata in the family member table 36, which is searchable for any person (registered user or otherwise) who has been designated as a family member of a user, and assigned a family member identifier (family _member_id) that is the primary key of this family member table 36, which also stores an owner-user identifier (owner_user_id) that serves to identify the owner of a family tree to which that family member identifier has been assigned in the family member table 36. Loading of the family tree visualizer in the GUI of a user device 12 of a given user will trigger a search of the family member table 36 for family members of the given user to plot in the family tree visualizer.

[0088] The family member table 36 also stores a family member-type identifier (member_type_id) that identifies the familial relationship of the family member to the owneruser of each family tree to which the family member belongs. In this illustrated example, this family member-type identifier is further defined in the member-type table 38, where there is stored a name of the familial relationship (e.g. husband, wife, father, mother, stepfather, stepmother, father-in-law, mother-in-law, grandfather, grandmother, uncle, aunt, cousin, brother, sister, stepbrother, stepsister, brother-in-law, sister-in-law, niece, nephew, son, daughter, grandson, granddaughter, etc.) and also a generation level identifier (generation_level) that is an integer value denoting a generational offset of a family member of this type to the owner-user a family tree to which that family member has been assigned in the family member table. The integer value of this generation level identifier thus dictates where to place the respective node in generational hierarchy of the family tree visualizer. In one optional implementation, generation level = 0 denotes the same generation as the owner-user of the family tree (e.g. spouse, husband, wife, brother, sister, cousin), generation_level = -1 denotes an immediately preceding generation to that of the owner-user (e.g. mother, father, aunts, uncles), generation level = -2 denotes two generations preceding that of the owner-user (e.g. grandmother, grandfather), generation level = +1 denotes an immediately subsequent generation to that of the owner-user (e.g. son, daughter, niece, nephew), generation level = +2 denotes two generations subsequent to that of the owner-user (e.g. grandson, granddaughter), etc.

[0089] A simplified, and perhaps more preferable, implementation that is instead used in Applicant’s prototyping of the system avoids use of any negative integers in the designation of generation level, and assigns generation level = 0 to any and all relationships belonging to any generation preceding the owner-user (parents, aunts, uncles, grandparents, great-grandparents), assigns generation_level = 1 to the same generation as the owner-user, and assigns generation_level = 2 and generation level = 3 in equivalent manner to levels +1 and +2 of the alternative implementation option described in the preceding paragraph. In this simplifiedimplementation, all members of any preceding generations are plotted together in a singular generic predecessor line of the visualized family tree shown in the GUI, and the complexity of mapping child / parent / sibling relationships among occupants of the preceding generation(s) in this predecessor line is avoided. In use, given that the purpose of the system is to compose and schedule future delivery of digital content to surviving loved ones in the event of the subject user’s death, the family tree is intended to be populated with only living family members, and so a full mapping of preceding generations is typically unnecessary, given that they will be notably less populated with living members. The definition of family members may be extended in some embodiments to include one or more particularly close / best friends, implemented for example by including BFF (Best Friend Forever) among the selectable family member types, while differentiating such familial-like friendships from the broader categorization of "friends" used to distinguish from "family" among the two different connection types. Typically, the BFF relation type would be assigned the same generation level in the family tree as the owner-user.

[0090] Figures 4, 5 and 6 respectively show three different scenarios through which a registered user of the system can add someone else to their family tree. Since such person(s) being added in one such scenario may be another registered user, the user adding to their family tree is referred to here as the subject user of this tree-populating process. As mentioned above, Figure 3B shows a family management menu 60 in the GUI, in which there is displayed a menu of selectable options for managing familial connections and functionalities, the first of which selectable menu options is an “add a family member” option 62A. Selection of this option 62A is schematically represented in the flowchart of Figure 4 at step 1001, in response to which the GUI, at step 1002, opens an “add connection” menu 64 shown in Figure 3E whose options include an “import from contacts” option 66 for importing details of the person they wish to add from an existing contacts list stored on the user device 12, and an ’’enter manually” option 68 for instead manually entering such details of the person to be added. Since there may be multiple users with the same name, preferably one or more pieces of uniquely personal data is / are used as mandatory identification that must be imported or entered as part of such personal details of the person to be added, such as a phone number or email address, or both thereof, which registered users will have stored in the database 28, in this case for both identification and notification / communication purposes. In some implementations, registered users must upload both their phone number and email address, and other users may search by either singular one thereof.

[0091] In response to import or manual entry of a person’s name and mandatory identification at step 1002, the user module 26E of the backend application 22 searches thepersons table 32 of the database 28 for any existing record of such mandatory identification (phone number, or email) as confirmation of whether that person yet exists in the system. If one or more matches are found, then the search continues by using a stored unique identifier of each matched person (person_id) from the person table 32 to search, at step 1003A, whether that person is also a registered user in the user table 30, and to search, at step 1003B, whether that person is already has an existing interpersonal connection to the subject user in the connections table 34. If no registered user or existing connection is found, as schematically illustrated at step 1003A, the non-user is added to the persons table 32 (which may be performed later at step 1006, in connection with updating of the connections table 34 and family member table 36) by the user module 26E of the backend application 22 using at least some of the imported or manually entered information on the sought person, which preferably includes at least one piece of contact information (phone number, and / or email address, in this case doubling as the mandatory identification of the sought person) by which the notification module 26C of the backend application can send an electronic message (text message, email, etc.) inviting that person to register. Regardless, having created an entry in the persons table 32 for that sought person, the subject user can nonetheless add that sought person as a family member (or a non-familial connection).

[0092] At step 1004, which appears after steps 1002 & 1003A-1003C in the illustrated example, though optionally may instead precede those steps in alternative implementations, the request to add a family member at step 1001 in the GUI of the mobile or web application 14A, 14B at some point triggers the API gateway to call on the user module to query the member-type table 38 of the database 28 for all possible types of family member available for the subject user to choose from for the sought person, and to display those selectable family member types in a member-type selection menu 69 of the GUI, as shown in Figure 3U, from which the user chooses, at step 1005, that which they wish to designate for the sought, or already found (depending on the order in which step 1004 is executed relative to steps 1002 & 1003A-1003C), person.

[0093] If a registered user was found at step 1003A or 1003B, then the GUI switches to a found-profile view 70 shown in Figure 3F, where the registered profile picture 50 of the found user is shown, in accompaniment by display of the username of the found user, as already registered in the user table 30. The illustrated example of Figure 3F shows an instance where the registered user is a parent or other guardian of two dependent children who are registered dependent users in the system, whose user registrations in the user table 30 are flagged as dependent users (is_dependent) and each include identification of the user identifier the registered parent / guardian user (guardian_user_id) that is the parent or other guardian of thedependent user.

[0094] To achieve such display of any dependent users in accompaniment to their parent / guardian user (of which only the parent / guardian is searchable by phone number or email address in the persons table, in which the dependent users are not recorded and thus do not have their own recorded phone numbers or email addresses), any positive finding of a user matching the searched phone number or email address triggers a secondary search for any dependent users whose stored guardian_user_id is the user_id of the matched user, so that any found dependents of that matched user can be specifically displayed as dependents thereof. Dependent users cannot be searched for by and connected to a searching user independently of the parents / guardians of those dependent users.

[0095] Dependent users interact with the system through their parent / guardian’ s user device and share account storage and posting capacity under that parent or guardian’s full-fledged account. This sharing of the parent / guardian's account by a dependent is visually demonstrated in Figure 3M, which shows an account summary screen 71 of the GUI for a dependent user, which account summary page is accessed via the “account” menu option on the main navigation menu 80 of Figure 3H. The account summary page 71 includes a storage capacity usage visually showing used fractions of the account’s overall storage capacity by the currently browsing user (in this case the dependent) and by all other users also registered to the same account. The dependent user functionality enables posthumous messages to be shared from deceased family members of such dependent users, who may be too young to have their own mobile phone, with the precaution that the parent or guardian has full access to the dependent user’s content feed and can thus pre-screen any posthumously released digital content from that deceased family member for appropriateness, before permitting view of such digital content by the dependent. The parent / guardian can likewise supervise creation of any digital content created by the dependent, or monitor created content of the dependent on their timeline, for any unsuitable behaviour or content that can be removed at the parent / guardian’s discretion. The GUI on a guardian’s user device is switchable to “dependent mode” via the “switch to dependent” menu option on the main navigation menu 80 of Figure 3H. Dependent users have no password, and so no password entry to required to switch from normal full-user (parent / guardian) mode to “dependent mode”, but entry of the guardian’s password is required to switch back from dependent mode to normal full-user mode.

[0096] In enablement of a dependent user’s sharing of their parent / guardian’s account, the user-subscription table 46 can have multiple users (user_id) assigned to each unique user account (user_subscription_id), where one of these users is a full user (the owner of the account)and any additional users are dependent users sharing that same account of the full user. Each dependent user record in the user table 30 may have a second parent / guardian identified therein (second_guardian_person_id), that identifies the second parent / guardian by their person_id, not their user_id, whereby the dependent is registered to only one account in the user-subscription table 46. The term subscription is used in representative relation to the illustrated embodiment, where users pay a monthly subscription cost for the service (of which there may be different tiers), but the term subscription may be substituted for account in relation to any functionalities, activities, processes, steps, etc. described herein that have no financial aspect, as there may be offered a “free account” option with limited functional and / or storage capacity, and / or timelimited to a free trial period. Fully free implementations of the system reliant on advertisement revenue or other revenue model that is not subscription based may also be possible.

[0097] In the present implementation with dependent users tied to their parent / guardian’ s account, the search for registered users or existing connections (e.g. by phone number and / or email address) should, typically if not always, result in only one of two possible results: a singular registered user, or a group of two or more registered users among which only one is a full-fledged user and each other one is a dependent user registered as a dependent of that full-fledged user. As shown, in Figure 3F the full-fledged user may be shown with an enlarged profile picture 50A of greater scale than the profile pictures 50 of the related dependent users, whose dependent relationship to the full-fledged user may also be visually conveyed by onscreen dependency lines 72 branching off from the profile picture 50A of the full-fledged user.

[0098] The found-profile view 70 of the GUI in Figure 3F includes an “add connection(s)” button 74 selectable by the subject user to add the located user (and optionally one or more displayed dependents thereof), at step 1006 of Figure 4, as a personal connection, and in this particular instance to add each located user(s) as a family member, given that the workflow in this scenario derived from initial section of “add a family member” at step 1001, though the same screen shown in Figure 3F is also usable in other instances to add non-familial connections. The screen of Figure 3F displays a "Select Connection Type" option for each located user, which when selected, may display a connection-type prompt 84 of the type shown in Figure 3K for choosing between friend and family connection types, from among which selection of the family option may then load the member-type selection menu 69 mentioned above (whose familial member types may again use an expanded familial definition that includes BFFs). In the case that familial connection is chosen at prompt 84, and a familial member type accordingly selected from menu 69, then at step 1006, the user module 26E of the backend application 22 thus populates a new record in both the connections table 34 and the familymember table 36, since a family member in this preferred implementation is a subcategory of a broader definition of a connection, the latter and broader of which denotes a person that the subject user can designate as a recipient of a posthumous release of digital content created and saved by the subject user prior to their death. The new connections record in the connections table 34 is composed at least of a unique connection identifier (connection_id), the unique user identifier (to_user_id) of the subject user (the user to whom the connection is being added, and to whose family tree that connection is also being added in this instance), the unique identifier of the person (from_person_id) being added as a connection and a family member (given than this person will exist in the persons table 32, but not necessarily the user table 30 depending on whether they are a registered user or not), and a family member identifier (fm_id) flagging this connection as a familial connection to a family member, for which a corresponding new record is being created in the family member table 36. The new family member record in the family member table 36 is composed at least of a unique family member identifier (family _member_id), the unique user identifier (owner_user_id) of the subject user (owner of the family tree to which the other person is being added), the unique identifier of the person (person_id) being added, the unique connection identifier (connection_id) of the corresponding connection record in the connections tables (34), and identification of the family member type (member_type_id) assigned at step 1005 from among those identified in the member-type table 38.

[0099] Having added a family member to the database 28 in such fashion, the family tree visualizer 48 in Figure 3A will inherently be populated with this added family member in any future loading and viewing of the family tree visualizer 48 given the newfound presence of this added family member in the family member table 36 from which the family tree visualizer 48 of Figure 3 A is populated. As mentioned earlier, step 1006 also includes adding a record to the persons table 32 if the person being added to the subject user’s family tree wasn’t already recorded in the persons table 32.

[0100] Figure 5 illustrates another interactive process between the subject user and the system for once again adding someone to the family tree of that subject user, but in the instance where the family member being added is an unborn future family member, not a currently existing family member as contemplated in the Figure 4 scenario. As mentioned above, Figure 3B shows a family management menu 60 in the GUI, in which there is displayed a menu of selectable options for managing familial connections and functionalities, which selectable menu options include a selectable “unborn child” option 62B for adding an unborn child to the subject user. Selection of this option 62B is schematically represented in the flowchart of Figure 5 at step 2001, in response to which the GUI, at step 2002, opens an “unborn relationship” menu 76shown in Figure 3J, which presents the user with various selectable options (via dropdown menu in the illustrated but non-limiting example) for the familial relationship of the unborn child being added, such as child, grandchild, great-grandchild, great-great-grandchild, etc.

[0101] Similar to the GetMemberType API call at step 1004 of Figure 4 to populate the family member type selection screen of Figure 3L, step 2002 of the Figure 5 process may trigger similar query of the member-type table 38 of the database 28 for all possible types of family member type available for the subject user to choose for the unborn child being created, but this time using an unbom-specific API call (getAHUnborn) that only retrieves a subset of the overall collection of family member types stored in the member-type table 38. Filtering of the unborn family member options may be done by use of flag in the member-type table 38 to distinguish between unborn-eligible and unborn-ineligible family member types, or alternatively may be based on use of the generation level indicators in the member-type table 38 to filter out the user’ s own generation and all preceding generations (presuming that adult users aren’t likely anticipating any as yet unborn siblings, and therefore limiting to the “unborn” functionality to descendent generations coming after the subject user’s own generation). In the illustrate example, the selectable family member types for the unborn is limited to direct descendants (children, grandchildren, great-grandchildren, etc.), and doesn’t include, for example, unborn nieces and nephews, though other embodiments may include expansion of the unborn functionality beyond the constrains of direct descendants.

[0102] Next at step 2003 of Figure 5, in equivalence to step 1005 of Figure 4, the subject user choses from the unborn relationship menu 76 which familial relationship type they wish to designate for the unborn child. The unborn relationship menu 76 of the GUI includes an “add to family” button 78 selectable by the subject user to add the unborn child of unnamed identity to the family tree at step 2004. At this step, the user module 26E of the backend application 22 populates new records in the family member table 36 and connections table 34 in similar fashion to step 1006 of Figure 4, and again flags the recorded connection as a familial one with a family member identifier (fm_id), and in this case also inherently populates a new record in the person table (given that the unborn is inherently a “new” person not already recorded therein), as the creation of connection and family member records in the connections table and family member table require a person_id from the persons table 32.

[0103] Having added an unborn child to the database 28 in such fashion, the family tree visualizer 48 in Figure 3A will inherently be populated with this added unborn child in any future loading and viewing of the family tree visualizer 48 given the newfound presence of this added unborn child in the family member table 36 from which the family tree visualization of Figure3A is populated.

[0104] Adding non-familial connections is performed by the subject user in similar fashion to the family member addition process of Figure 4, for example after first using the main GUI navigation menu 80 seen in Figure 3H to navigate to the connections management screen shown in Figure 3K, and selecting the “add connection(s)” option 82 provided on this screen. Selection of the “add connection(s)” option 82 may bring up a connection-type prompt 84 asking whether the intended connection is a familial one, or not, for example framing this option as “family” or “friend” as shown by overlaid prompt in the same Figure 3K. Selection of “family” from such option triggers the process of adding an existing family member, as already discussed with relation to Figure 4. Selection of the alterantive option (e.g. “friend”), triggers execution of the same steps 1002, 1003A andl003C, but without family-specific steps 1003B, 1004 and 1005, and instead followed by a modified version of step 1006 that adds a connection to the connections table 34 without a family member indicator (FM_id), lacks any addition to the family member table 36, and includes addition of a record to the persons 32 table if the newly connected person wasn’t already recorded in the persons table 32 or users table 30. After successful addition of the new connection, as with successful addition of a new family member, a confirmatory acknowledgement of the successfully added connection may be shown on screen, as shown at 86 in Figure 3G.

[0105] Figure 5A illustrates two different interactive processes between the system and two different users, each of which process is operable to effectively link digital content created for an unborn child of a family tree that was not yet bom at the time of the digital content creation (essentially an unnamed placeholder node in the family tree) to an actually realized family member later bom in the same generation to which that unborn child placeholder was originally assigned. Without this linking of a unborn placeholder node in the family tree to an actually realized family member, created / uploaded content designated by the uploader / creator for later release to an unborn future family member will never be successfully shared and seen, and so this content linking process is schematically shown at step 3000 as an inevitable follow-on to the Figure 5 workflow of adding an unborn child to the family tree. In practice however, the account linking itself could come years or decades later, and so the actual implementation steps are illustrated separately as steps 3001 and 3002 in subsequent Figure 5A.

[0106] In one instance, illustrated at step 3001, this unborn-to-newborn content linking is triggered by inputted action on the part of the same subject user that created / uploaded the digital content, and that is the recorded owner of the family tree to which that unborn child node belongs. The inputted action in this case is for the subject user to perform addition of a familymember in similar fashion to that outlined above in relation to Figure 4, but skipping step 1002 and instead starting from 1003C since the newborn child will not have a searchable phone number or email address, other than those of their parents. If at least one of those parents is a registered user of the system, then they are likely already members of the subject user’s family tree, in which case the subject user can instead rely on the parents of the newborn child to register the newborn child as dependent user under one of their accounts, as contemplated further below in the other unbom-to-newborn content linking option, which will render it unnecessary for the subject user to add the newborn child themselves. In the presence instance, at steps 1003C and 1004 (in that or the reverse order), the subject user enters the name of the newborn child and specifies their relationship to the subject user (the same relationship originally specified for the unborn child previously added to the subject user’s family tree). The user module 26E of the backend application 22, based on the same AddFamilyMember API call in step 1006 of the Figure 4 process, will add a new family member record to the family member table 36, add a new family-flagged connection record to the connections table 34, and add a corresponding record in the persons table 32, in equivalence to step 1006 of Figure 4, thereby adding an entirely new family member with the name entered at step 1003C.

[0107] This newly added family member in the subject user’s family tree does not replace the previously created unborn child node, which remains as a placeholder for another potential future child yet to be born. To link the digital content previously created and scheduled for release to an unborn recipient to this newborn child freshly added to the family tree, the AddFamilyMember API call also triggers a search for any unborn child nodes that already exist in the family tree at the time of the newborn child’s addition thereto and are found to have the same assigned generational level as the newborn child just added to the family tree. Finding of any such unborn child at the same generational level as the added newborn triggers further search of the content table 44 for content records in which the unborn child was assigned as a designated recipient (person_id). On positive finding of any such content records, the designated recipient data in that record is updated to add the person_id of the newly added newborn child. The result of this is that any digital content previously specified for release to the prior unborn child is now scheduled for release to the newly added newborn child, but also remains effectively scheduled for any future unborn children of that same generation that may be yet to come. Any newly created digital content subsequently created and specified for release to the unborn child placeholder (which remains in the family tree) will not be inherently released to the newly added newborn child, and will only be scheduled for release thereto if this newly added newborn child is specifically designated as an intended recipient of that new digital content.As mentioned above, the other unbom-to-newborn content linking option, also illustrated in Figure 5A, as step 3002, is instead one that is the result of user action by a registered user that is a parent of the newborn, which parent-initiated content linking option replaces the need for action by the subject user in the event that the subject user is alive, and one that is the only viable option when the subject user has already died before the birth of the newborn child. In this scenario, when the parent adds a dependent user, or a family member whose familial relationship is designated as a child of the parent, the addDependent or addFamilyMember API call is followed by a checkParentHasUnbom API call to check whether any member in preceding generations of the parent’s family tree has any unborn children in their family trees that generationally match the newly added dependent / child. If a match is found, then this triggers further search for content records in the content table 44 that were created by the deceased, and in which the unborn child was a designated recipient (person_id). On positive finding of any such content records, the designated recipient data of such record is updated to add designation of the newly added newborn child, in the same manner described above, such that any digital content previously specified for release to the prior unborn child is now scheduled for release to the newly added newborn child, while the effectiveness of the unborn child node remains intact for similar content linking to any future unborn children of that same generation that may be yet to come. This parent-initiated content linking option may also include another execution of the AddFamilyMember API call, this time specifying addition of the newly added family member of the parent to the family tree of the deceased subject user, thus keeping the family tree of the deceased user updated despite the deceased status of that user.

[0108] Returning to the family management menu 60 shown in Figure 3B, a “manage dependents” option 62C is present therein and selectable by a user to navigate to the dependent management screen of Figure 3C, which shows a dependency map 87 of any existing dependents already existing under the user’s account, and includes an “add a new dependent” button 88, for initiating the process of adding a dependent at step 4000 of Figure 6 using the dependent profile creation form 90 shown in Figure 31, which includes on or more name fields 92A-92C for the dependent’s full name, a relationship menu 94 of selectable options for the relationship of the dependent to the user (for example populated at step 4001 using the same GetMemberType API call used for adding a family member in Figure 4, and noting that though many guardian / dependent relationships will be parent / child, many other possibilities are also supported in this implementation), a date of birth field 96, a place of birth field 98 (omitted in some embodiments for compliance with data privacy policies or regulations), and at least one secondary guardian designation menu 100 (e.g. dropdown menu) for user-selectableidentification of at least one secondary guardian of the dependent (such selectable options being populated from the family members and connections of the user, among which selection of at least one secondary guardian may be mandatory in some embodiments).

[0109] The dependent profile creation form 90 includes a save button (equivalent to that 102 shown in an editable dependent profile form 90’ of Figure 3D that shares the same fields as the dependent profile creation form 90) for saving the entered data once the form is completed, which triggers an addDependent API call at step 4002 in the illustrated workflow of Figure 6. This API calls triggers creation of a new user record in the user table 30, in which the is_dependent flag is set to true, the guardian_user_id field is set to the user_id of the user who created the dependent (primary guardian), and the second_guardian_person_id field is set to the secondary guardian specified in the dependent profile creation form 90, if specified or mandated. As part of such creation of the dependent user, the user module 26E of the backend application 22 may automatically populate the connections table 34 with connections for the new dependent user that are equivalent to those of the parent / guardian for any connections thereof for which the connection is flagged as a family member (fm_id), thus establishing automatic connection of the dependent user to all family members of the parent / guardian.

[0110] The dependent user may add other connections in the same manner available to full-fledged users, and can likewise create a family tree in the same manner as the full-fledged users. When the parent / guardian switches to “dependent mode” for the first time after creation of a first dependent, or selects for the first time one of a plurality of created dependents in a dependent selection menu displayed in dependent mode when switched to, the GUI preferably invites the dependent to “import family” into their family tree from among the family-flagged connections in the parent / guardian’ s existing connections, as shown in the dependent-user import family screen 116 of Figure 30. If the user chooses the “import family” option 118, then the “import connection” screen shown in Figure 3P is loaded, and populated with the family-flagged connections from the parent / guardian’ s existing connections in the connections table 34, from which the dependent user can pick and choose which family-flagged parent / guardian connections to import. On confirmation of the selection with the “import / invite” button 120, the GUI then switches to a “set relationship” screen 122 shown in Figure 3Q, where the dependent can individually assign any of the available familial relationship types using a pop-up membertype selection menu 124 shown in Figure 3R (equivalent to that of Figure 3L). The dependent user can then choose the “add connections” option 126 on the set relationship screen 122 of Figure 3Q to populate those imported family members into the dependent user’s family tree.

[0111] When any other user adds a parent / guardian as a family member, for examplefrom the found-profile view 70 of the Figure 3F scenario where the dependents of the parent / guardian are visibly plotted beneath the parent / guardian, this other user has the option of selecting only the parent / guardian, or the combination of the parent / guardian and any one or more of the dependent(s) thereof, whose addition to the family tree is schematically denoted at step 4003 of Figure 6. Given that a dependent is not always a child of the guardian, and that the relationship of the dependent to the owner of a family tree to which the guardian is being added is therefore not necessarily self-evident and easily derivable from a reading of the stored data, addition of any dependent user to a family tree may include invitation of the owner of that family tree to designate a familial relationship of each dependent of the parent / guardian to the owner of that family tree, for example using the same or a similar member-type selection menu 124 as that shown in Figure 3R.

[0112] In some embodiments, optional assignment of more than one secondary guardian to any dependent is permitted, as demonstrated in Figure 3D by the "add another guardian" option, to ensure continuity of the dependent account. In such instances where multiple secondary guardians have been assigned, and the primary guardian is reported as deceased, or has selected a selectable "Resign as Guardian" option that may be included on the dependent management screen of Figure 3C or elsewhere, then the system sends a first one of the designated secondary guardians a notification inviting them to assume the role of primary guardian for the dependent. If this first secondary guardian refuses the invitation to assume primary guardianship, or does not take responsive action to the invitation within a set time period, then the system sends equivalent invitation to the next secondary guardian, and so forth until either one of the secondary guardians accepts the invitation to assume primary guardianship, or the populated list of secondary guardians has been fully exhausted with no acceptors of the invited takeover of primary guardianship. Preferably, each acceptance or declination of an invitation to assume primary guardianship by an invited secondary guardian triggers the system to issue an informative notification of that acceptance or declination to the resigning primary guardian. Each such notification preferably includes the identity of the secondary guardian that accepted or declined the invitation to assume primary guardianship, and in the case of a declination by a secondary guardian among an unexhausted list of multiple secondary guardians, preferably includes indication that the system will automatically issue invitation to the next secondary guardian in the as-yet unexhausted list of secondary guardians, or indication that the system has already done so. In alternative embodiments, notification to the resigning primary guardian in such instances of declined invitation among a non-exhausted list may prompt the resigning primary guardian whether to issue the next invitation, or to terminate the attempted resignation,in which embodiments the prompted issuance of the next invitation may optionally include userselection by the primary guardian of which secondary guardian to invite next, if multiple secondary guardians yet remain among the unexhausted list of as-yet uninvited secondary guardians. In the instance of a secondary guardian's declination of an invitation to assume primary guardianship, the system may automatically remove that secondary guardian from the user table of the dependent user, and the notification of that secondary guardian's declination of primary guardianship that is sent to the primary guardian preferably communicates that such removal has taken place.

[0113] If all secondary guardians decline their invitation to assume primary guardianship, then the primary guardian (if not deceased) is notified that the attempted resignation of guardianship has failed, so that reattempt of such resignation can be undertaken again, subject to the primary guardian's addition of a new secondary guardian for the dependent user in question. If the primary guardian has been recorded as deceased, then a system administrator is instead notified of the declined assumption of primary guardianship by the secondary guardians, thus enabling the administrator to take further action, such as contacting the family to find out if there is a new legal guardian for the dependent. In at least some embodiments, designation of at least one secondary guardian by the primary guardian may be a mandatory requirement during the creation of a dependent user. If a secondary guardian assumes the role of primary guardianship when so invited by the system to do so, then the guardian_user_id in the user table of the dependent user whose guardianship is being changed is repopulated with user_id of the secondary guardian who has agreed to assume the role of primary guardianship, whose person_id is then removed from the second_guardian_person_id in the user table of the dependent user, given that their guardian role has changed from secondary to primary.

[0114] Having described user-addition of existing family members, unborn future children, dependents, and other personal connections, and also the linking of already created content for unborn children to newborn children once actualized, all for the purpose of posthumously delivering digital content to specifically designated recipients thereamong on behalf of a deceased user, attention is now turned to the creation, or uploading and customization, of such digital content, and scheduling of such recipient-targeted release thereof to those designated recipients.

[0115] Figure 7 A illustrates a content-creation home screen of the GUI, with a scrollable menu for selection of formats in which digital content can be recorded or composed, for example including video recording, photo capture, text composition and voice recording. Figure 7A seesthe content creation home screen being operated in video mode, with a record button shown for such video capture. Figure 7B shows the same content creation home screen being operated in photo mode, with a photo capture button instead shown in place of the video record button of Figure 7B. Figure 7C shows the GUI having been switched into a message composition screen by user-selection of the message composition option of the content-creation home screen, so that the user can enter a written message, whether through typed input or voice-to-text capability (if implemented). Figure 7D shows the GUI having been switched into an audio recording screen by user-selection of the voice recording option of the content-creation home screen, so that the user can record an audible voice message (or any other recordable audio). With the exception of the text composition option, recording or capture of the other types of content (video, photo, voice) may be followed by prompted invitation to add a written note to the user-created content. As shown in Figure 7E, this prompt for optional tagging of the digital content with a written note may appear on a same screen on which the subject user is invited to save the digital content alone (e.g. “quick save”), or navigate to a content release configuration menu for assigning content release-governing data to the digital content to govern future scheduled release thereof to designated recipients (“message options”). The content creation home screen can also include an upload button for uploading of a pre-existing digital photo, video, audio recordings, and / or documents in alternative to unique creation thereof, which can then be further customized (like freshly created content) using editing tools of the content creation service 24A, and optional user addition of the written note.

[0116] Figure 7F shows a first section of the content release configuration menu of the illustrated embodiment, which in this instance is a multi-screen menu, but need not necessarily be in other embodiments. On the first screen of this multi-screen content release configuration menu is a recipient designation menu where the user selects which of their connections (existing and unborn family members, and other non-familial connections) to assign as designated recipients of the digital content in question, for example via checkbox assignment of one or more connections appearing in this menu, which are populated in the GUI by an API call triggering querying of the connections table 34 for the connections of the subject user with which to populate the recipient designation menu. A multi-selection tool, for example a “my family” button, may select multiple contacts of a certain category, in the example automatically selecting all connections flagged as family members. Referring to Figure 7G, the content release configuration menu may include a tag assignment menu for optional assignments of one or more categorical tags to the digital content (funny, advice, diary, etc.). The content release configuration menu may includes a scheduling type selection menu presenting differentscheduling options by which the system can govern the release of the digital content, which in the illustrated example of Figures 7G include: date-based scheduling, age-based scheduling and custom event-based scheduling.

[0117] Figure 71 shows a date -based scheduling menu accessed by selection of the datebased scheduling option in the Figure 7G menu, where the subject user can select a death-related date of predefined timeline relation (e.g. day after, week after, month after, etc.) to a death date on which the subject user has died, or has been confirmed / presumed to die based on input to the system, which death date is stored in the user table 30 of the database (date_of_death). The user can alternatively enter any calendar date on which the subject user wishes the digital content to be released to the designated recipient(s) assigned in the recipient designation menu of Figure 7F. This date-based scheduling menu may include an option for entering a particular time of day on which to release the content on the chosen calendar date. Given that the subject user’s date of death is typically not known in advance, the illustrated implementation of this menu includes a selectable postponement option for postponement of the release by some predefined interval (e.g. one year) if the user has not died by that chosen calendar date (if date_of_death is not yet assigned as of the chosen calendar date). If the postponement option is not selected (e.g. toggled on), and the chosen calendar date passes in absence of an assigned death date, then in some embodiments the digital content release scheduled for that date is skipped altogether.

[0118] In other embodiments, if the postponement option is not selected, then the date-scheduled message will send on the scheduled date regardless of the user's life status. In these embodiments, this date-based scheduling may be the sole option for sending messages during the lifespan of the user, or optionally one of two scheduling options among which age-based scheduling is also capable of pre-death (prehumous) messaging, and which functionality may be promoted as particularly beneficial for use by military members to ensure that their family will hear from them on important occasions, even if they are deployed or otherwise unable to communicate. In such embodiments that permit sending of scheduled messages during the lifespan of the user (meaning prior to setting of the subject user's deceased flag to deceased), the system may be configured to enable the subject user to add themself as one of their connections, which in turn enables the subject user to assign themself as one of the designated recipients, or even the sole designated recipient, of a scheduled message that may ultimately be delivered within their lifespan. In the case of naming themself as one of multiple intended recipients, the message gets populated into the subject user's own feed, enabling them to enjoy the posted message concurrently to the release thereof to the other designated recipients. In the case of naming themself as the sole designated recipient, this enables, for example, a subject user tosend themself a private message to their future self (e.g. a happy birthday video to themself on a future birthday, should they survive to see it). For such purpose, the "add connection" menu 64 in Figure 3E may be programmed to include an "Add Me" option (which like all other menu options reference herein may vary in its naming convention, in this case for example reworded as "Add Self" or "Add Myself"). Alternatively, and perhaps more preferably, addition of the user's self to their family tree may be an automated functionality of the system that requires no self-addition process by the user.

[0119] Figure 7J shows an age-based scheduling menu accessed by selection of the agebased scheduling option in the Figure 7G menu, where the subject user can select from among themself and any other registered users among their connections (each of whom have a date of birth (dob) saved in the user table and an age of that selected user (in at least years, and optionally years plus days as shown) at which to trigger scheduled release of the digital content in question. As with the calendar date option in Figure 71, the age-based scheduling menu may include a time-of-day option for specifying particular time of day at which to release the digital content on the day of specified user age of the chosen user (the subject user themself, or any of their connections), and again may include a postponement option for postponement of the release by some predefined interval (e.g. one year) if the user has not died by the day of specified user age (if date_of_death is not yet assigned as of the day the specified user age is achieved).

[0120] Figure 7K shows a custom scheduling menu accessed by selection of the custom scheduling option in the Figure 7G menu, where the subject user can create a custom eventbased trigger for release of the digital content based on occurrence or passage of any user-chosen life event in the life of a user-chosen connection of the subject user. A connection selection menu (e.g. drop down box) populated by query of the connections table for the connections of the subject user is displayed for the subject user to choose the particular connection whose specified life event is to be used to trigger scheduled release of the digital content in question, along with an event specification field or menu (e.g. text field) where the user can enter a particular life event (or choose from predefined life event options), such as a wedding, buying a home, school graduation, first date, pregnancy, childbirth, bar mitzvah / bat mitzvah, quinceanera, sweet sixteen, obtaining a drivers license, etc. A verification selection menu is populated with registered users found among the subject user’s connections, from which the subject user can choose one or more verifiers of the life event whose input to the system is required in verification that the life event of the chosen connection has occurred. The connections selectable by the user for the purpose of custom life-event scheduling of a digital content release may be intentionally limited to registered users.The content release configuration screen of Figure 7G, toggled to a timeline plotting mode in Figure 7H, in supplement to the date-based, age-based and custom event-based scheduling options, here instead displays a timeline plotting tool where the user can instead plot a release for the digital content on a post-death timeline, on which already plotted content releases for previously created digital content are already mapped out, optionally with colour-coded markers according to their tagged categories. Content releases plotted in the timeline plotter may be referred to herein as timeline messages, in distinction from the content releases that are user-scheduled based on date, age or custom event, which are instead termed scheduled messages. In the illustrated example, the content release (timeline message) being plotted is shown centrally on the displayed timeline as an enlarged colour marker relative to smaller markers of previously plotted releases, and the timeline is scrollable back and forth relative to the enlarged colour marker to resituate its relative position therealong and relative to the already mapped releases previously plotted thereon.

[0121] To enable user selection between scheduled and timeline messages during message creation, the content release configuration menu of Figure 7G incudes a toggle for user selection between whether to configure the message as "timeline" or "trigger" based. As already described above, selection of the "trigger" designation invites the user to set a date, age or custom trigger of a scheduled message. If the user instead selects the "timeline" option, then the timeline plotter of Figure 7H is displayed and used, and the menus of Figures 71 to 7K are bypassed. For composed timeline messages, instead of being assigned a scheduled date or other type of release trigger, the system assigns a timeline position indicator (e.g. integer variable "position" in content table 44) representative of where that timeline message will fall in the user's timeline relative to other timeline messages likewise created for timeline-based release, rather than user-scheduled release. By default, the timeline position indicators are assigned sequentially, as incremental integers 1, 2, 3, etc., as timeline messages are composed. Activation of the timeline is triggered by setting of the user's is_deceased flag to deceased, whereupon the system will implement automated control over the release the timeline messages in sequential fashion at chronologically spaced intervals. Timeline messages are intended to be a catchall for any messages that the user wishes to send posthumously, but for which the user doesn't have any specific date, age or custom triggers in mind.

[0122] Timeline messages assigned to the timeline can thus be treated as "drafts" of messages that the user wishes to ultimately have sent, but does not, at least at the time of original composition, have an inclination as to when they should be specifically sent. After composition, the user may have permission and ability to later edit at least a subset of their timeline messagesat any time, by accessing the message editor of Figure 70 from the timeline popup in Figure 7N, and choosing the "edit" option in the Figure 70, to load message option menus of equivalent or comparable content to those of Figures 7F and 7G, from which menus the user can optionally reconfigure the timeline message as a scheduled message. In some embodiments, there may a "message permanentization" option by which a user can optionally choose to make a message permanent (uneditable), which are thus excluded from the editable subset, though in other embodiments lacking such permanentization capability, all messages may instead be editable. For any timeline messages that are not converted to scheduled messages before death, the system will automatically send those timeline messages, in their saved sequence, at spaced intervals over the duration of the user's timeline. Using the timeline messaging option, users can upload lots of content quickly to build up their digital legacy and know that their families will get a steady stream of messages from them postmortem, without the user getting bogged down in the decision-making of specific trigger events for each individual message.

[0123] In one version of the timeline plotting tool illustrated in Figure 7H, other versions of which may differ therefrom, a group (e.g. three) of timeline message thumbnails are displayed above the timeline axis, among which one (e.g. middle one) of the thumbnails is shown in enlarged scale (or otherwise emphasized fashion) relative to the others, which the emphasized (and typically middle) thumbnail denotes the current timeline message being drafted, and the relatively unemphasized (e.g. smaller scale) remainder of the thumbnails in the displayed group denote the sequentially adjacent timeline messages that are slated for release sequentially preceding and following the current timeline message. The sequential display of timeline message thumbnails shown concurrently in the timeline plotter are typically labeled with their respective timeline position indicators (22, 23, 24 in the illustrated example) denoting where they fall within the overall sequence of the totality of plotted timeline messages. Underneath the timeline axis on which the timeline messages are plotted is displayed a quantified post-death timing interval (e.g. number of days and years) indicative of how long after the subject user's death that the currently viewed message will be released (Year 2, Day 15 in the illustrated example), the value of which is dependent on the current quantity and sequential order of plotted timeline messages relative to the user’s timeline duration. This quantification will thus change (under automated recalculation by the system) based on the position of the current message relative to other timeline messages, the total number of timeline messages on the user's overall timeline, as well as the set duration of the timeline over which those messages are to be distributed.

[0124] In at least some preferred embodiments, the default timeline position of a newlydrafted timeline message is the sequential position immediately following the most recently plotted one of any previously plotted timeline message (message #22 in the illustrated example of Figure 7H). In this timeline plotting tool, the user can swipe left or right on the screen to reposition the current message into a different sequence among the presently displayed group of timeline messages, based on which the system will update the position variable in content table 44, and which will ultimately cause the current message to be released sooner or later postmortem than the current message's initially plotted (default) position on the timeline. So for example, swiping all the way to the left would reassign the current message to the chronologically first spot on the timeline (causing system change of the position variable to 1, and system incrementation of the position variables of the other timeline messages that previously preceded the current message), thereby rendering the current message as the slated first message to be released after death of the subject. Swiping all the way to the right would instead reassign the current message to the chronologically last spot on the timeline (causing system change of the position variable to a numerical value equal to the total quantity of timeline messages, including the current draft timeline message, and system decrementation of the position variables of the timeline messages that previously followed the current message), thereby the current message as the slated final message to be posted X years after the user has died (with "X" being a capped duration of the user's timeline, which may be dictated by user-adjustable settings in some embodiments, or by predetermined system or subscription settings in others). For example, if message #24 in Figure 7H is the slated final message (rightmost on the timeline), and message #23 is repositioned to the final rightmost spot on the timeline, message #23 is renumbered by the system as #24, and #24 (which previously followed #23) is decremented to #23. This designation of the current timeline message as the slated final timeline message will remain valid, so long as no other timeline message is later placed at the far right extreme of the timeline axis of the timeline plotter before death of the subject user, which would instead bump the previously slated final timeline message one spot leftward in the sequence and take its place as the slated final timeline message.

[0125] In embodiments with user adjustability of the timeline duration, the timeline duration may be adjusted, for example, between one and one hundred years within the user settings (though the extremes of the selectable range of timeline duration options may vary). The system's default timing of timeline messages plotted to the timeline may be one of temporally equidistant (isochronal) interval (same amount of time between any two sequentially adjacent timeline messages). In one non-limiting example, if a user creates thirteen timeline messages before death, and has a timeline duration of one year, then system-activation of the user'stimeline (when is_deceased is set to true) will trigger automated release of the thirteen composed timeline messages at approximately one-month intervals from one another (e.g. 30.35 days, calculated as one twelfth of 365.25-1, i.e. the number of days in a year minus the first day on which the first message is sent, divided by the number of message intervals, which is equals the number of messages minus 1), starting with release of the first timeline message on Day 1 of the one-year timeline, and terminating with release of the final timeline message on Day 365 of the one-year timeline. Under the same isochronal implementation, a one-year timeline populated with fourteen messages before death would instead equate to a message release frequency of one timeline message per 28.02 days, while a one-year timeline populated with 365 timeline messages would equate to a message frequency of one timeline message per day (assuming a non-leap year). If the same user, having composed 365 timeline messages, adjusted, before death, their timeline duration to ten years, then the isochronal message frequency would instead be one message approximately every ten days (10 years, at 365.25 days a year = 3652.5 days, divided by 364 message intervals, = message frequency of 10.03 days).

[0126] Generalized, the system may calculates the message frequency, in the isochronal interval scenario, as fm= (Ta - Df) / (Nm- 1), in which fmis the message frequency (in days), Ta is the timeline duration (in days), Df is the day of the first timeline message (e.g. Df = 1 means the first timeline message will be sent on the first day of the timeline), and Nmis the total number of timeline messages (from which it follows that Nm- 1 = the total number of message intervals). Df may be fixed in some embodiments, or be a user-adjustable variable in other embodiments, for example in case some users may feel that a posthumous message on Day 1 of the timeline may be too emotionally overwhelming. The post death timing interval of each timeline message (in days) can be calculated as Ti = Ptx fm, where Ti is the post-death timing interval (in days), and Ptis the timeline position of the timeline message. For compound display of the post-death in years and days, Tyears,days — INT(Ti I 365.25), M0D(Ti, 365.25), and the timeline plotter can be programmed to hide the calculated years when INT(Ti / 365.25) = 0, so that messages slated for the first post-death year show their post-death intervals solely in days (Tdays).

[0127] In preferred embodiments, the system recalculates the message frequency of timeline messages each time a new timeline message is created by the user, and also any time the user's timeline duration is changed in the user settings, so that in the timeline plotter of Figure 7H or the timeline viewer of Figure 7N, the quantified post-death timing interval of each timeline message plotted on the timeline axis (e.g. expressed as years + days from death) is properly calculated and displayed according to both the current quantity of composed timeline messages and the current duration of the timeline. It will be appreciated that isochronal messagingfrequency on the timeline is just one example of a workable method of system-automated message plotting on a user timeline, and that a decaying message frequency may alternatively be employed, where timeline messages are delivered at greater frequency (lesser interval) initially post mortem, during peak mourning of the deceased user by friends and family, and then at lesser frequency later on in the timeline, which variable frequency is preferably tapered off in gradual fashion over time. Selection between an isochronal and a decaying timeline message frequency may be an available user-selectable option in a user settings menu. Activation of a user's timeline at death, performed in association with setting of is_deceased to true, includes formalization of the post-date timing intervals of the sequentially-plotted timeline messages into release dates for those messages, given the known date of death and the timeline message frequency. The calculated date values are assigned to the release dates (publish_date) of the timeline messages in the content table 44 for timely release of the timeline messages by the timeline module 26E.

[0128] Each of the scheduling menus among Figures 7H to 7K has a selectable finalization button (labelled “safeguard my message” in the illustrated example) that the user selects once the designated recipient and scheduling information has been entered in the navigated content release configuration menu, which triggers upload and encrypted storage of the recorded digital content to the data storage service 24B, and creation of an associated record in the content table 44 of the database 28, which contains at least a unique identifier of the stored digital content (content_id), the unique identifier of the subject user that created the digital content (user_id), one or more encryption keys associated with the encrypted storage of the digital content (e.g. separate content and thumbnail keys for retrieval of the digital content itself and a representative thumbnail image thereof, aws_content_key & aws_thumnail_key), any assigned category tags (tag_ids), identification of the connection(s) that were designated as recipients of the digital content (person_id), and, unless death-related or life-event scheduling was assigned to the digital content, a scheduled release date (published_date) on which the digital content is to be released to the designated recipients (e.g. entered as a calendar date in Figure 71, or calculated as a user’s stored date of birth plus the age inputted in Figure 7J). Upon successful upload and associated creation of the digital content record in the content table 44, the GUI confirms the creation of a scheduled content release to the subject user, for example with the summary screen shown in Figure 7E.

[0129] Figure 7M shows a user-settings menu accessible off the main navigation menu of Figure 3H, which user settings menu includes selectable deceased-status triggers by which the system will categorize subject user as being deceased, and accordingly set a deceased flag(is_deceased) in the subject user’s record of the user table 30 to reflect such deceased status, and record the death date of the subject user (date_of_death). In the particularly illustrated example of this figure, one selected deceased-status trigger options is a user activity trigger, where the subject user’s lack of interaction with the system for more than a predetermined period of time is used to trigger recategorization of the subject user as deceased. The illustrated example uses passage of more than the predetermined period of time (of which several options may be presented, e.g. via drop-down menu) between successive user logins of the subject user as the measurable threshold for recategorization of the user from living to deceased. Another illustrated example of a selectable deceased-status trigger option in this particular figure is a family-inputted trigger, where a registered user found among the connections in the subject user’s family tree can designate the subject user as deceased, for example by visiting a profile page or pop-up menu via the subject user’s node in that other user’s family tree, which profile page or pop-up menu has a “report death” button by which such designation is made, triggering recategorization of the subject user as deceased. In preferred embodiments, the selectable deceased-status trigger option for reporting a family member as deceased is available only to full-fledged users, and not to dependent users. As schematically illustrated, another option may be included for similar reporting of the subject user’s deceased status by a healthcare provider. Inclusion of the “report death” button 104 on a viewable user profile is visually demonstrated in Figure 3D, under the editable dependent profile form 90 on a dependent profile screen of the GUI, and in Figure 3T discussed further below.

[0130] In other, and more preferable embodiments, an alternative approach is taken in regard to recategorization of a user from living to deceased, one that implements a requirement for further verification before changing the subject user's status to deceased, preferably implemented in the form of a family member voting procedure, initiation of which is spurred by either of the aforementioned deceased-status triggers: the user activity trigger, or family-inputted trigger. Preferably, in response to either deceased-status trigger, the system automatically signs the presumed-deceased user out of their account on any devices they may be logged in on, and sends the presumed-deceased user a notification (email, text message and / or robocall) inviting them to sign back in to their account within a designated period of time (life confirmation period, e.g. 24-hours) as authentication that they have not actually died. Such confirmation of life by the presumed-deceased user prevents initiation of the family voting procedure. Implementation of the life confirmation period may be a user selectable option that can optionally be bypassed in user settings, for example as an extra option in the user settings menu of Figure 3M. Login by the presumed-deceased user within the life confirmation period may be subject to furtherverification of life to prevent initiation of the family vote, for example email and / or phone number verification sending a one-time-password (OTP) by email and / or text message or robocall, for which OTP the presumed-deceased user would be prompted to enter in the GUI to complete the life confirmation process that will prevent initiation of the family voting procedure that otherwise may result in a death-indicative voting result. Upon successful life verification, the presumed-deceased user can resume normal use of the application.

[0131] On the other hand, in instances where the system detects passage of the life confirmation period with no login by the presumed-deceased user, the system looks up all nondependent family members of the presumed-deceased user and triggers transmission of voting notifications thereto, for example sending in-app push notifications, email notifications and / or text message notifications to those non-dependent family members that are registered users, and email and / or text message notifications for those non-dependent family members that are unregistered persons. Emailed voting notification, and an in-app voting menu linked to from the in-app voting notification, presents the notified family member with two voting options concerning the actual life status of the presumed-deceased user: Alive or Dead, and may also include a cancel option allowing them to cancel out of the voting action, but typically allowing the family member to later complete the voting action (though in other embodiments, the cancellation option could alternatively be implemented as a tool for that family member to decline participation in the family voting process altogether). In association with issuance of the voting notifications, the system starts a voting period (e.g. 48 hours) during which the votes must be received, upon expiration of which the ultimate living / deceased status determination of the presumed-deceased user will be made by the system, based on the family member voting results. In-app voting notifications are preferably implemented in a prominent fashion with reappearing or consistent display of a voting reminder to the user, given the importance of the voting procedure (e.g. implementation of the voting reminder as a home screen overlay that reappears on each return to the home screen). As a backup redundancy to the life confirmation period, any login by the presumed-deceased user (preferably conditional on the secondary life verification step referenced above) during the voting period may trigger termination of the voting process. Such termination would involve deactivation of the in-app voting reminders, and reconfiguration of the landing page of the voting links in the email notifications from what was previously a voting page to an advisement page instead informing the family member that the presumed-deceased user has since been found active, and thus confirmed as living.

[0132] Upon system determination of either the expiration of the voting period, or receipt of a respective vote from each of the family members that were sent voting notifications, thesystem calculates a voting result of the votes cast by the family members (limited to one vote per member), and then ultimately changes or maintains the status of the deceased flag of the presumed-deceased user depending on whether the voting results confirm a deceased or living status of the presumed-deceased user. The voting result may be determined on majority-vote basis among the votes actually cast, using a 50% threshold among the actual votes received from the invited family members, though the particular death-affirming vote threshold employed may vary in other embodiments (e.g. instead requiring a 60% or other supermajority threshold to be met to conclude a death-affirming result). In the event of a vote result that reaches but doesn't cross the death-affirming vote threshold (e.g. in the event of a 50-50 tie vote in the 50% threshold example), the system may default to a presumed living status, rather than changeover to a deceased status, though the default may be set to the contrary in other embodiments. In conjunction with switchover of the deceased user's status to deceased, their account is locked out by the system, which disables the login credentials of that account, whereafter scheduled release of the deceased user's posthumous messages will proceed in the scheduled manner according to the populated message timeline. The system is preferably configured such that any attempted login to the deceased user's account triggers display of a locked-account notice advising the user that they were reported as deceased, that the account has accordingly been locked out, and that their posthumous messaging timeline has been activated. Such notice preferably includes presentation of system administrator contact details (e.g. email address, phone number) to enable the locked out user to pursue rectification of their incorrectly recorded death.

[0133] In some embodiments, if no votes are cast, or the tallied votes fail to cross the necessary death-affirmation threshold (e.g. in the case of a 50-50 tie vote in the 50% threshold example), determination of such inconclusive voting result by the system may trigger to the system to initiate a second vote, without switching the presumed-deceased user's status to deceased, given the inconclusive result of the first vote. If the second vote again results in no votes or an inconclusive result, the system should flag the matter for further attention by a system administrator. Preferably the system also implements one or more safeguards against repeated false reporting or voting of users as deceased, when they are not actually deceased. In one embodiment, if the deceased-status trigger was a family-inputted trigger, and the vote result is a life-affirming result, not a death-affirming result, the system's finding of a life-affirming vote result is followed by a responsive flagging of the user account that reported the false death with a false-report flag, which flagging mechanism in some embodiments may be implemented as a counter, which is incremented by one with each detected false report, thus imparting the systemwith a degree of false-reporting forgiveness, where a first such false report doesn't immediately impart penalization of the user who falsely reported the death (false death reporter). Upon incrementing the false-report counter to one, some embodiments may promptly provide a warning notice (in app, or by email, text message or robocall) to the false death reporter, advising them that the reported death appears to have been false, and that further false reports may have one or more consequences (e.g. restriction of death reporting and / or voting permissions, temporary or permanent account suspension, or some other consequence). Alternatively, such warning notice may alternatively be presented to the false death reporter only upon a subsequent attempt to report the same or another user as deceased.

[0134] Once a predetermined quantity of forgivable false reports is exceeded, then the system implements the aforementioned penalization of the false reporter (through account limitations like restriction of voting and / or reporting permissions, or alternatively a full account suspension, whether temporary or permanent). A similar false voting safeguard may be implemented in substantially the same fashion to the false reporting safeguard, again optionally implemented via a falsity counter that is incremented in each instance of a confirmed falsity performed by the user (in this case a false vote, whose falsity was proven by a conclusive voting result of contradictive life status to that user's particular vote), and imparting consequences (reporting / voting permission restrictions, temporary or permanent account suspension, etc.), but only once a forgiveness threshold of forgivable falsities is exceeded. In one embodiment thought to optimally balance the seriousness of false reporting / voting with a limited degree of forgiveness, only one falsity is forgiven, and a second falsity results in consequential action (i.e. false_counter > 1 = consequence).

[0135] Figure 7N shows a timeline screen accessible from the main navigation menu of the GUI, where the subject user can view a visualization of their post-death timeline and all timeline messages already created and plotted thereon, as well as all scheduled messages, which are preferably also visualized here to enable a single viewing of all uploaded message of any type together on a singular timeline visualization, though there may an options menu by which the timeline visualizer on this timeline screen can be filtered by message type to only show timeline messages, only scheduled messages, or both thereof. Further filtering options may be included for further refinement of scheduled messages by trigger type (date, age, custom event). The term uploaded messages may be used herein as an all-encompassing term for both scheduled and timeline messages that have been uploaded to the database (the "uploaded" designation being used in contrast to a message being "drafted" in the manner described above in relation to Figure 7H, and not yet formally uploaded in a finalized manner ready for automated posthumousrelease). Preferably, a plotted marker of each uploaded message on the timeline axis of this timeline visualization has a thumbnail representation of the digital content (photo, video screenshot, written message), preferably tagged with the name(s) of the designated recipient(s) and optionally any written note (or a truncated fragment thereof), so that each uploaded message is easily recognizable by the subject user. The thumbnail has an “edit” button thereon, selection of which switches the GUI into the editor screen shown in Figure 70, where the subject user can optionally edit various data of the uploaded message, such as the designated recipient(s), tags, and in the case of a timeline message, can optionally reconfigure the timeline message as a scheduled message triggered by date, age or event, or can optionally delete an uploaded message entirely (if not made permanent via the aforementioned optional permanentization option referenced above).

[0136] In the timeline visualizer, all custom event triggered messages may be plotted on the timeline axis in a grouped fashion at a rightmost region of the timeline following all timeline messages and all date and age triggered messages of the scheduled type, since their release dates are as yet indeterminate given the untriggered status of the custom event. Alternatively, instead of individual plotting of the custom event triggered messages on the timeline axis of the timeline visualizer, a singular thumbnail or button labelled something like "View Custom Trigger Event Messages" may instead be displayed as a selectable option to ring up a list view of the custom event triggered message, which may itself be another timeline-like display of the uploaded custom event triggered messages. In the timeline visualizer, the timeline messages are plotted on the timeline axis forwardly of the present date by a distance proportional to the post-death timing interval at which the timeline message would be released after death. With each viewing of the timeline visualizer over a timespan of one or more days, scheduled messages triggered by age or calendar date will shift leftward toward the present date given the advancement of time between sequential viewings of the visualizer, while the timeline messages remain static, as will scheduled messages that are set to be triggered according to a specified "Day After Death", as set in Figure 71.

[0137] The timeline module 26D of the backend application 22 monitors the release dates (publish_date) of the content records in the content table for whom the subject user’s deceased status is true, and on determination of both conditions being true , triggers notification, by the notification module 26C, of the designated recipient(s) of the scheduled or timeline message, for example by in-app notification and to any such designated recipient that is a registered user, which notification informs the user that their in-app feed, accessible off the main navigation menu, has been updated with new content. For any designated recipient (connection,but not a registered user) notification is instead sent by text message and / or email to the designated recipient, based on the phone number and / or email address for that designated user in the persons table of the database, which notification may contain a URL by which the released digital content is viewable by that non-user recipient, or instead may only invite the non-user recipient to register as a user in order to gain access to the released digital content of the given message from the deceased subject user.

[0138] Figure 7P shows a screenshot of a browsing user’s feed, showing a released digital content post from a deceased user, optionally marked with an R.I.P. (rest in peace) overlay indicative of the deceased user’s deceased status, and a timestamp of when the content was recorded (createdAt from content table 44). As shown, the released digital content post may have functionalities for commenting and liking thereof, similar to digital content feeds in common social media applications, whereby the designated recipients can interact communally with other loved ones on digital content that the deceased user chose to share with multiple recipients. The released digital content post includes a header with the profile picture and name of the deceased, which may be marked with an R.I.P. or other deceased-status indicator, and is preferably an interactive button whose selection by the browsing user pulls up the a deceaseduser synopsis shown in Figure 7Q, on which there may be displayed any one or more of the deceased user’s death date, city of last known residence, birthdate, place of birth, and a brief written biography, all of which are retrieved from the user table 30 of Figure 2A, all having been previously inputted by the subject user of the digital content (while still alive) on a profile configuration screen of the GUI, shown in part in Figure 7R, and then stored for later use. As already mentioned previously regarding place of birth, city of last known residence may also be omitted in some embodiments for compliance with data privacy policies or regulations.

[0139] One inventive aspect of the dependent user functionality of the system is the ability to emancipate dependent users from their parent / guardian’s account, and assign the formerly dependent user a full account of their own and thereby render them a full-fledged user responsible for their own subscription and use of the system. One preferred implementation of this emancipation process is illustrated in Figures 8 and 8A, of which Figure 8A is a continuation of the workflow steps shown in preceding Figure 8.

[0140] Initial step 5001 of the emancipation process is one initially triggered from the GUI by the parent / guardian of a dependent, for example starting with selection by the parent / guardian of the “manage dependents” menu option 62C in family management menu 60 shown in Figure 3B in order to load the dependent management screen of Figure 3C. In response to such selection, the client device performs a GetAllDependents API call, which searches theuser table 30 for any user records for which the isDependent flag is set to true and for which the Guardian_user_id field contains the user_id of the parent / guardian, and uses any such located user records to load the dependency map 87 in the dependent management screen of Figure 3C. Each dependent’s profile pic in the populated dependency map 87 is an executable link, userexecution of which by the guardian will load the dependent profile screen of Figure 3D with the aforementioned editable dependent profile form 90’. This dependent profile screen includes a “delete dependent" button 106 that can be chosen to delete the dependent user entirely, for example in the event that the dependent has reached an independent age but does not want to continue using the platform, and thus has no interest in becoming a full-fledged user with their own account. Instead however, the guardian can select the alternative “emancipate this dependent” button 108 to initiate emancipation of the dependent user from the guardian’s account, and transition the formerly dependent user to a full fledged user with their own independent account.

[0141] Selection of this emancipation option 108 opens up an emancipation initiation screen 110 shown in Figure 3N, in which the guardian is prompted to enter contact information (mobile phone number, email address, or preferably both thereof) of the dependent to be emancipated, for example in the illustrated email and phone number fields 112A, 112B, and to confirm initialization of the emancipation process, for example via confirmation button 114. Clicking of the confirmation button 114 triggers step 5002 of the Figure 8 emancipation process, in which the user module 26E of the backend application 22 updates an emancipation status field (emancipation_status) in the user table record of the dependent whose emancipation is being initiated by the parent / guardian, setting this emancipation status field to “requested” for the interim period, as this preferred implementation of emancipation process will require the authorization of the currently dependent user themselves before recategorizing them as a full-fledged user.

[0142] Request of such authorization from the dependent user is performed at step 5003, where the notification module 26C of the backend application 22 sends out an emancipation authorization request (email or text message) to the dependent user being emancipated using the entered contact information therefor in the emancipation initiation screen 110 of Figure 3N. This emancipation authorization request, typically an email, contains a login ID (e.g. the email address of the dependent), and in some embodiments an auto-generated temporary password, by which the dependent user can login to the system independently of the guardian’s account. The user module of the backend application 22 writes the email address of the dependent user (as entered in the emancipation initiation screen 110) to the email field of that dependent user’s userrecord in the users table 30, and writes the auto-generated temporary password to the password field in that same user record of the users table 30, thus enabling login of the currently dependent user to the system via this newly created email-based login and temporarily assigned password.

[0143] The emancipation authorization request may embody therein an “emancipation acceptance” button. At next step 5004 of the emancipation process, the dependent user receives the emancipation authorization request email, and clicks the emancipation acceptance button embodied therein, which button preferably has a deep-link functionality by which the dependent user is redirected either to a login screen of the mobile application 14A (if installed on the dependent user’s user device 12), or to an application store at which the dependent user can download the appropriate version of that mobile application 14A for the operating system of their user device 12, so that the dependent user can then run the downloaded application and login with the email-based login and temporary password. Login to the system by the dependent user through the mobile application 14A may itself, or even the preceding click of the emancipation acceptance button in the email, may be treated as the dependent user’s authorization to emancipate from the account of the guardian, in response to which the user module 26E of the backend application 22 will update the emancipation status field in the user record of the dependent user from “requested” to “confirmed”. In some embodiments, dual verification may be required, with emancipation authorization requests issued both to the email and phone number (e.g. as a text message or robocall) of the dependent, with verification required from each before the user can login. In some embodiments, issuance of a temporary password in the emancipation authorization request may be omitted, with alternative reliance on simple email and / or phone number verification process, where a one time password (OTP) password is instead sent as part of the emancipated user's first time login procedure to grant access to a first time login, which then triggers prompted creation of a new user-created password to use from thereon to access the emancipated user's account.

[0144] Having confirmed the dependent user’s authorization of the guardian’s emancipation request, the remaining step 5005 of the emancipation process in Figure 8A is to fully delink the emancipated dependent user from the account of the guardian, and in place of this prior account sharing, instead setup the emancipated dependent user with their own full-fledged account. In achievement of this, the user module 26E of the backend application 22 updates the guardian_user_id and second_guardian_person_id in the user record of the emancipated dependent to null values, and changes the is_dependent flag of that user record from true to false. In the illustrated embodiment, different account subscription plans (with different monthly, annual or other periodic subscription renewal costs) entitle full-fledged users(and their dependents) to different data storage capacity limits for their created digital content depending on their plan, and impart different limits on a quantity of scheduled content releases the user create, dynamic quantifications of which are stored in the user-subscription table 46 as storageAlloted and messageAlotted. Additional fields storage_used and message_used in the user-subscription table 46 denote the quantity of data storage and message capacity used out of those allotted quantities. These used capacity fields of the parent / guardian’s subscription record are updated to remove the fraction of the used storage capacity previously used by the emancipated dependent user, which used capacity is reassigned to the emancipated dependent user’s now-independent plan, given their new full-fledged status. In first loading of the family tree visualizer of the emancipated user, which will be prepopulated according to the already established familial connections from the formerly dependent account of the emancipated user, the system may prompt the emancipated user to consider whether there are missing members in their family tree, and invite the emancipated to use the family member addition option 62A to add to their family tree.

[0145] Revisiting Figure 3A, the preferred implementation of the family tree visualizer 48 is scrollable in two dimensions, scrollable vertically to move inter-generationally among the plotted generation levels of the visualized family tree, and scrollable horizontally to move intra-generationally to view the full membership among any generation level whose members occupy more than a singular screen width of the user device’s display screen. In demonstration of this, Figure 3S illustrates the same family tree visualizer 48 as Figure 3A, but scrolled to a different subregion of the visualized family tree to reveal additional family members (existing and unborn) not visible in Figure 3 A. As will now explained in more detail, the family tree visualizer 48 is also an interactive menu from which the browsing user (owner of the visualized family tree) can access various functionalities relating to the family members plotted in the visualized family tree.

[0146] Figure 3T illustrates a living family-member popup menu 130 loaded by user selection of a plotted family member in the family tree visualizer, which popup menu includes a “compose message” option 132 whose selection redirects to the content-creation screen of Figure 7 A where the browsing user can compose digital content for scheduled release to the chosen family member; a “view profile” option 134 whose selection redirects to a browsable profile (not shown) of the chosen family member, an “edit relationship” option 136 for user-editing of the familial relationship of the chosen family member to the browsing user, for example via a dropdown or radio button menu like that of Figure 3 J or 3L; a “manage dependents” option 138 displayed in instances where the chosen family member is a dependent of the browsing user, andwhich redirects to dependent management screen of Figure 3C or straight to the dependent profile screen of Figure 3D for the dependent family member concerned; and a family-member removal option 140 whose selection removes the chosen family member from the browsing user’s family tree.

[0147] The family tree removal option may double as a user blocking option that (in the event that the chosen family member is a registered user) populates the blocked users table 40 with a record of the browsing user’s user identifier (user_id) and the user identifier of the family member being blocked (blocked_user_id). The timeline module, in connection with any scheduled release of digital content, may cross-check the person_id of each designated recipient of a scheduled digital content release against the users table, and if the designated recipient is a registered user, then check the blocked users table to ensure that the deceased user who scheduled the digital content release has not been blocked by the designated recipient. The family -member popup menu 130 may further comprise a dedicated blocking option for blocking the family member, without full removal thereof from the family tree, so that the blocked family member remains visible in the family tree visualizer, despite their blocked status, for example to retain better continuity in the visualized family tree. The family-member popup menu 130 of the illustrated example includes a “report death” option 142 by which the death of the family member (who is a registered user) can be reported to the user module, which then sets the is_deceased flag to true for that deceased family member. The family-member popup menu 130 may also have a follow / unfollow toggle for following or unfollowing the content channel of the family-member.

[0148] The family -member popup menu 130 of the illustrated example also includes a trigger-event verification option 144 in instances where the browsing user had previously been designated, in the scheduling menu of Figure 7K by another now-deceased user, as a verifier for a life event in the life of the living family member of the popup menu 130. Selection of this option 144 by the browsing user may redirect to the custom trigger verification screen 146 of Figure 3U, which plots synopses of any such life events along a timeline axis 148. These life events are identified at least by name of the user whose life event is being verified and the type of event, as saved in the database from the deceased user's prior use of the custom scheduling menu of Figure 7K, along with name of the event verifier(s), to collectively denote event data representative of the subject user's intention that occurrence of this life event, and verification thereof by one of the verifiers, is a conditional timing requirement to be fulfilled in order to trigger system release of the deceased user's scheduled message composed specifically for chronological association with the anticipated life event. Selection of any such plotted life eventsynopsis 150 on the timeline axis 148 may load a larger scale event verification menu 152 shown in Figure 3 V, where the browsing user can verify the life event using a verification button 154. Use of the verification button may prompt password entry (as confirmation of the verifier’s identification), successful entry of which then display a verification confirmation, as shown in Figure 3W. This verification triggers the timeline module 26D to execute release of the custom scheduled digital content release previously setup by the now-deceased user. Referring back to Figure 3A, in addition to the content release recipient identifier 54 by which the browsing user of the family tree visualizer can see how many scheduled digital content releases they’ve created for the family member of any node in the visualized family tree, a content release verification identifier 55 may be shown to denote that the browsing user has been designated as a verifier on one or more custom-scheduled content releases for that family member, which identifier may be a numerical identifier indicative of the quantity of such scheduled releases for which the browsing user is an assigned verifier of the family member’s life event.

[0149] Finally, Figure 3X illustrates a deceased family -member popup menu 156 that is shown for any deceased member in the browsing user’s visualized family tree, in alternative to the living family-member popup menu 130 of Figure 3T. This menu 156 differs from menu 130 in its lack of the “compose message” option (and the “manage dependents”, especially if the deceased family member was not a dependent of the browsing user), and, in the illustrated example representative of an embodiment with solely post-humous message capability, in its unique inclusion of a “view timeline” option 158 that is lacking in the living family-member popup menu, given that living family-members have no posted messages to yet view in such embodiment. The browsing user can select this “view timeline” option 158 in order to view any released digital content on the deceased user’s timeline for which the browsing user was named as a designated recipient, as well as any messages posted publicly by the deceased for broad visibility among all users, rather than limited viewing by only designated recipients, in embodiments with such public posting capability. In such embodiments, messages may still need to be addressed to designated recipients, but the message creation and scheduling process may include a private / public toggle option, for example like that shown in Figure 7F, whose setting to private vs. public determines whether the message is ultimately visible to solely to the designated recipients (private) or to a broader user base (which in preferred embodiments constitutes the entirety of registered users, regardless of whether they have a connection to the messaging user, but in other embodiments could alternatively be limited to connected users only). In embodiments distributing public messages to registered users at large, the system preferably populates a user's feed using a prioritization scheme that prioritizes recently postedcontent by that user's connections, followed by public messages from non-connections, among which further prioritization may be based on higher ranking of those with high user interaction (most views, comments, likes or combinations thereof) than those with lesser user interaction. A more thorough prioritization scheme may include the following post categorizations, for example, but not necessarily, of ranked priority matching the sequence in which they are listed: 1) Dead family posts addressed to the user; 2) Dead connection posts addressed to the user; 3) Alive family posts addressed to the user; 4) Alive connection posts addressed to the user; 5) Non-connection posts addressed to the user; 6) Public family posts that are not addressed to the user; 7) Public friend connection posts that are not addressed to the user; 8) Public posts from non-connection channels the user follows; and 9) Public posts from the highest engaging (most liked and / or commented) non-connection channels that the user doesn’t follow.

[0150] Any deceased family member node in the family tree visualizer may be visually marked as such, and further marked with a “viewable content” identifier if digital content by that deceased family member has been released to the browsing user as a designated recipient, thus serving as prompt for the browsing user to pull up the deceased family member’s timeline to view such content. The “viewable content” identifier may only be displayed for as yet unviewed content releases, or may be displayed differently (e.g. different colours, tagging of the indicator with a “new” tag, etc.) depending on whether there is newly released and unviewed content available, or only previously released content already viewed by the browsing user. In aforementioned embodiments capable of posting at least some of a subject user's messages during their lifespan (prehumous posting), the living family-member popup menu and the family-tree visualizer can likewise include equivalent "view timeline" options and "viewable content" identifiers for living connections.

[0151] The family tree visualizer is thus a fully functional menu in which a browsing user can interact with family nodes in several ways, from the perspective of planning and creating digital content releases (often shorthanded herein as "messages") for their family members, viewing digital content releases (messages) from their deceased family members, and modifying membership (relationship changes, removal / blocking) within their family tree.

[0152] Since various modifications can be made in the invention as herein above described, and many apparently widely different embodiments of same made, it is intended that all matter contained in the accompanying specification shall be interpreted as illustrative only and not in a limiting sense.

Claims

CLAIMS:

1. A system for automated posthumous release of digital content created or uploaded by a subject user prior to death for later consumption of said digital content by one or more intended recipients, said system comprising:one or more computing devices communicable with other computing devices over one or more communications networks, and comprising thereamong:one or more processors;one or more non-transitory computer readable media having stored therein computer readable code executable by said one or more processors;data storage in which said digital content is stored;one or more databases for storing therein data concerning said subject user, said one or more intended recipients, and said digital content;wherein said computer readable code is configured to, when executed, perform at least the following steps:(a) store, in said one or more databases:family tree data representative of a family tree of the subject user, one node of which is representative of the subject user, and other nodes of which are each individually representative of a respective existing or unborn family member of the subject user, and are each represented in said family tree data, at least in part, by reference to another member of said family tree and a relationship specifier that specifies a familial relationship between said existing or unborn family member and said other member of said family tree;release-governing data for one or more scheduled releases of the digital content from the subject user to the one or more intended recipients, said release-governing data comprising:for each one of the one or more scheduled releases, content identification data denoting identification of an entirety or subset of the digital content created by the subject user as subject content for said each one of the one or more scheduled releases;for each one of the one or more scheduled releases, scheduling data indicative of intended timing at which to trigger said one of the one or more scheduled releases; andfor each one of the one or more scheduled releases, recipient identification data indicative of at least one intended recipient for said each one of the one or more scheduled releases, among which the recipient identification data for at least one of the one or more scheduled releases comprises identification of at least one member of the family treethat has been designated, based on recipient selection input from the subject user, as said at least one recipient for said at least one of the scheduled releases; and(b) for at least one of the one or more scheduled releases, and after recategorization of the subject user as a deceased user, release of the subject content of said at least one of the one or more scheduled releases both:in a scheduled manner conditional on confirmed fulfillment of a conditional timing requirement dictated by the scheduling data of said at least one of the one or more scheduled releases; andin a recipient-targeted manner specifically released to the at least one intended recipient identified by the recipient identification data of said at least one of the one or more scheduled releases.

2. The system of claim 1 wherein the family tree data of least one user comprises both named family member data that denotes, and identifies by name, at least one existing family member of known name to the user, and unborn family member data that denotes at least one unborn future child, as yet unborn and unnamed.

3. The system of claim 2 wherein the computer executable code is further configured to, upon addition of a new family member to the family tree at a same generational level as the unborn future child, modify the recipient identification data for at least one of the scheduled releases to include identification of the new family member.

4. The system of claim 3 wherein said computer executable code is configured to modify said recipient identification data in least one of the following instances:(i) user-addition, by the subject user, of the newborn family member the family tree of the subject user; and / or(ii) other user-addition, by a related user of familial relationship to the subject user, of the newborn family member to a respective family tree of said related user.

5. The system of claim 4 wherein said computer executable code is configured to recipient identification data in at least instance (ii), and in such instance, automatically add said newborn family member also to the family tree of the subject user.

6. The system of claim 4 wherein said computer executable code is configured to modify said recipient identification data in at least instance (i), and in such instance, leave the unborn future child in the family tree of the subject for further use thereof by the subject user to schedule content release for at least one other future family member as yet unborn.

7. The system of any preceding claim wherein the release-governing data comprises identification of another user as a verification source from whom verification ofoccurrence or passage of a variably -timed event of unknown date is to be used as input to trigger at least one of said one or more scheduled releases.

8. The system of claim 7 wherein said release-governing data, in accompaniment to identification of said verification source, also comprises identification of a person, of personally known relation to both the subject user and the verification source, in whose life said variably-timed event is an anticipated life event.

9. The system of any preceding claim wherein the said computer readable code is configured to cause display, in a user interface of a user device communicable with said one or more computing devices over said one or more communication networks, a visualization of the family tree for navigation thereof by the user.

10. The system of claim 9 wherein the visualization of the family tree is a scrollable visualization.

11. The system of claim 9 or 10 wherein the visualization of the family tree displays a profile picture of at least a subset of existing family members in the family tree.

12. The system of any one of claims 9 to 11 wherein the visualization of the family tree is an interactive menu, within which the subject user can interact with the visualization in at least one of the following ways:create a new scheduled release designating a displayed family member as one of the one or more intended recipients of said new scheduled release;check how many scheduled releases have the displayed family member designated as one of the one or more intended recipients;access any scheduled release already released, or at least view notification of any scheduled release already released, of digital content created by the displayed family member that designates the subject user as an intended recipient;report the displayed family member as deceased, which in the case of the displayed family member being another subject user of the system, triggers executed and scheduled release of any scheduled releases previously created by said displayed family member; and / orverify occurrence of a life event in a life of the displayed family member, and thereby trigger release of another user’s digital conditional that was scheduled for conditional release on fulfillment of said life event.

13. The system of any preceding claim wherein the release-governing data for at least one of the one or more scheduled releases, includes event data representative of at least one anticipated future life-event, passage of which denotes fulfillment of the conditional timingrequirement that triggers release of the subject content of said one of the one or more scheduled releases.

14. The system of claim 13 wherein step (b) comprises, for said one of the one or more scheduled releases, and before release of the subject content thereof, first receiving event confirming input data from another user indicative of passage of said anticipated future event, thereby denoting said confirmed fulfillment of the conditional timing requirement, and thereafter releasing the subject content of said subset of the one or more scheduled releases in said targeted manner.

15. The system of any preceding claim wherein user data in the one or more databases comprises categorized user data distinguishing between full-fledged and dependent users, among which dependent users are linked to accounts of associated full-fledged users, and the computer readable code is further configured to perform at least one of the following:prohibit user-searching of the dependent users independently of their associated full-fledged users;automatically populate found-user results of any user search with both any found full-fledged user matching entered search criteria of said user search and any dependent linked to the account of said any found full-fledged user matching said entered search criteria;require password confirmation to switch a user GUI of a full-fledged user's device from a dependent mode to a normal full-user mode;execute, in response to user input, a user-initiated emancipation process that decouples a dependent user from an account of the associated full-fledged user of said dependent user, and reassigns said dependent user a new non-dependent status and a new login separate of said associated full-fledged user.

16. The system of any preceding claim wherein said one or more computing devices comprise one or more servers.

17. The system of claim 18 wherein said one or more databases are hosted among said one or more servers.

18. The system of any preceding claim wherein said one or more computing devices further comprise a user device of the subject user.

19. The system of any preceding claim wherein said one or more computing devices further comprise one or more respective recipient devices of the one or more intended recipients.

20. The system of claim 19 wherein the release of the subject content of each one of the one or more scheduled releases to the one or more intended recipients thereof comprisesone or more of:posting the subject content of the one or more scheduled releases to respective content feeds viewable on the one or more respective recipient devices of said one or more intended recipients;triggering notification of the one or more scheduled releases in an application running on the one or more respective recipient devices of said one or more intended recipients, through which application the one or more intended recipients interface with the system;triggering notification of the one or more scheduled releases via text message delivered to the one or more respective recipient devices of said one or more intended recipients; and / ortriggering notification of the one or more scheduled releases via email readable on the one or more respective recipient devices of said one or more intended recipients.

21. The method of claim 20 comprising triggering notification by at least one of either said text or said email, which said text or said email includes a link to at least one of either (a) a viewable posting of the subject content of said one of the one or more scheduled releases; or (b) a resource for downloading the application, in which the subject content of said one of the one or more scheduled releases can be viewed.

22. The system of any preceding claim wherein the conditional timing requirement for at least one of the one or more scheduled releases comprises a particular date on which said one of the one or more scheduled releases is to be released in automated fashion.

23. The system of any preceding claim wherein:said computer readable code is further configured to, when executed, store, in said one or more databases, timeline message data for posthumous communication of timelinebased messages composed by the subject user before death, said timeline message data comprising additional identification data denoting identification of subject content, from among the digital content created or uploaded by the subject user, for each one of said timeline-based messages, and additional recipient identification data indicative of at least one intended recipient for said each one of said timeline-based messages;step (b) comprises, after said recategorization of the subject user as deceased, release of the timeline-based messages, independently of the scheduled releases, at system-calculated intervals.

24. The system of claim 23 wherein said system-calculated intervals are calculated, based at least in part, on a quantity of said timeline-based messages composed by the subject user before death, and a timeline duration over which said timeline-based messages areto be released.

25. The system of claim 23 or 24 wherein said timeline message data comprise message sequence data indicative of a sequential order in which said timeline-based messages are to be released.

26. The system of any one of claims 23 to 25 wherein said computer readable code is further configured to, when executed, present to the subject user, before death, a timeline plotting tool on which a series of said timeline-based messages are plotted for visualization to the subject user of anticipated posthumous timing of messages.

27. The system of any one of claims 1 to 22 wherein said computer readable code is further configured to, when executed:store, in said one or more databases, timeline message data for posthumous communication of timeline-based messages composed by the subject user before death, said timeline message data comprising additional identification data denoting identification of subject content, from among the digital content created or uploaded by the subject user, for each one of said timeline-based messages, and additional recipient identification data indicative of at least one intended recipient for said each one of said timeline-based messages;present to the subject user, before death, a timeline plotting tool on which a series of said timeline-based messages are plotted for visualization to the subject user of anticipated posthumous timing of messages; andin step (b), after said recategorization of the subject user as deceased, release the timeline-based messages28. The system of claim 26 or 27 wherein said timeline plotting tool is operable by the subject user to chronologically reorder said timeline-based messages into a different chronological order.

29. The system of any one of claims 26 to 28 wherein timeline plotting tool displays a quantified post-death timing interval of each timeline-based message.

30. The system of claim 29 wherein said computer readable code is further configured to, when executed, recalculate said post-death timing interval in any instance of:user addition or deletion of any one or more of the timeline-based messages; and / oruser or administrator change of the timeline duration for the subject user.

31. The system of any one of claims 23 to 30 wherein said computer readable code is further configured to, when executed, present the subject user access to a message editor through which one of the timeline-based messages is convertible into another scheduled releaseby user-input of additional scheduling data for the previously timeline-based message.

32. A computer-implemented method of implementing automated posthumous release of digital content created by a subject user prior to death for later consumption of said digital content by one or more intended recipients, said method comprising performance, by one or more computing devices communicable with other computing devices over one or more communications networks:(a) storage in one or more databases of:family tree data representative of family tree of the subject user, one node of which is representative of the subject user, and other nodes of which are each individually representative of a respective existing or unborn family member of the subject user, and are each represented in said family tree data, at least in part, by reference to another member of said family tree and a relationship specifier that specifies a familial relationship between said existing or unborn family member and said other member of said family tree;release-governing data for one or more scheduled releases of the digital content from the subject user to the one or more intended recipients, said release-governing data comprising:for each one of the one or more scheduled releases, content identification data denoting identification of an entirety or subset of the digital content created by the subject user as subject content for said each one of the one or more scheduled releases;for each one of the one or more scheduled releases, scheduling data indicative of intended timing at which to trigger said one of the one or more scheduled releases; andfor each one of the one or more scheduled releases, recipient identification data indicative of at least one intended recipient for said each one of the one or more scheduled releases, among which the recipient identification data for at least one of the one or more scheduled releases comprises identification of at least one member of the family tree that has been designated, based on recipient selection input from the subject user, as said at least one recipient for said at least one of the scheduled releases; and(b) monitoring for fulfillment of a conditional timing requirement dictated by the scheduling data of said at least one of the one or more scheduled releases to trigger release of the subject content thereof in a recipient-targeted manner specifically released to the at least one intended recipient identified by the recipient identification data of said at least one of the one or more scheduled releases.

33. A system for automated posthumous release of digital content created oruploaded by a subject user prior to death for later consumption of said digital content by one or more intended recipients, said system comprising:one or more computing devices communicable with other computing devices over one or more communications networks, and comprising thereamong:one or more processors;one or more non-transitory computer readable media having stored therein computer readable code executable by said one or more processors;data storage in which said digital content is stored;one or more databases for storing therein data concerning said subject user, said one or more intended recipients, and said digital content;wherein said computer readable code is configured to, when executed, perform at least the following steps:(a) store, in said one or more databases, timeline message data for posthumous communication of timeline-based messages composed by the subject user before death, said timeline message data comprising identification data denoting identification of subject content, from among the digital content created or uploaded by the subject user, for each one of said timeline-based messages, and recipient identification data indicative of at least one intended recipient for said each one of said timeline-based messages;(b) present to the subject user, before death, a timeline plotting tool on which a series of said timeline-based messages are plotted for visualization to the subject user of anticipated posthumous timing of messages; and(c) after recategorization of the subject user as a deceased user, release the timeline-based messages at chronological intervals over a timeline;further characterized by at least one of the following:(i) said one or more databases also have stored therein scheduled message data for posthumous communication of user-scheduled messages likewise composed by the subject user before death, said scheduled message data comprising additional identification data denoting identification of subject content, from among the digital content created or uploaded by the subject user, for each one of said scheduled messages, additional recipient identification data indicative of at least one intended recipient for said each one of said scheduled messages, and scheduling data indicative of user-intended timing at which to trigger said one of the one or more scheduled releases, and step (c) comprises releasing the timeline-based messages independently of the user-scheduled messages at timeline intervals;(ii) presentation to the subject user, in step (b) after plotting at least a subset ofthe timeline-based messages, of a timeline visualization on which both of the timeline messages and the user-scheduled messages are viewable as a collection of uploaded messages slated for posthumous release, and from which editing access to at least a subset of said uploaded messages is accessible to the subject user for user-reconfiguration of said collection;(iii) presentation to the subject user, in step (b) after plotting at least a subset of the timeline-based messages, a message editor through which a selected one or more of the timeline-based messages are convertible into another scheduled release by user-triggered assignment of newly assigned scheduling data to the selected one or more of the timeline-based messages and(iv) calculation of the timeline intervals in dependent relation to a total uploaded quantity of said timeline messages an assigned duration of the timeline.

34. The system of claim 33 characterized by inclusion of at least further characterization (i).

35. The system of claim 33 or 34 characterized by inclusion of at least further characterization (ii).

36. The system of any one of claims 33 to 35 characterized by inclusion of at least further characterization (iii).

37. The system of any one of claims 33 to 35 characterized by inclusion of at least further characterization (iv).

38. The system of any one of claims 33 to 37 wherein at least one of either said timeline plotting tool or said timeline visualization is operable by the subject user to chronologically reorder said timeline-based messages into a different chronological order.

39. The system of any one of claims 33 to 38 wherein at least one of either said timeline plotting tool or said timeline visualization displays a quantified post-death timing interval of each timeline-based message.

40. The system of claim 39 wherein said computer readable code is further configured to, when executed, recalculate said post-death timing interval in any instance of:user addition or deletion of any one or more of the timeline-based messages; and / oruser, administrator or automated system change of the timeline duration for the subject user.

41. A computer-implemented method of implementing automated posthumous release of digital content created by a subject user prior to death for later consumption of said digital content by one or more intended recipients, said method comprising performance, by oneor more computing devices communicable with other computing devices over one or more communications networks:(a) storage in one or more databases of timeline message data for posthumous communication of timeline-based messages composed by the subject user before death, said timeline message data comprising identification data denoting identification of subject content, from among the digital content created or uploaded by the subject user, for each one of said timeline-based messages, and recipient identification data indicative of at least one intended recipient for said each one of said timeline-based messages; and(b) presentation to the subject user, before death, of a timeline plotting tool on which a series of said timeline-based messages are plotted for visualization to the subject user of anticipated posthumous timing of messages; and(c) after recategorization of the subject user as a deceased user, release the timeline-based messages at chronological intervals over a timeline;further characterized by at least one of the following:(i) further storage in said one or more databases of scheduled message data for posthumous communication of user-scheduled messages likewise composed by the subject user before death, said scheduled message data comprising additional identification data denoting identification of subject content, from among the digital content created or uploaded by the subject user, for each one of said scheduled messages, additional recipient identification data indicative of at least one intended recipient for said each one of said scheduled messages, and scheduling data indicative of user-intended timing at which to trigger said one of the one or more scheduled releases, and step (c) comprises releasing the timeline-based messages independently of the user-scheduled messages at timeline intervals;(ii) further presentation to the subject user, in step (b) after plotting at least a subset of the timeline-based messages, of a timeline visualizer on which both of the timeline messages and the user-scheduled messages are viewable as a collection of uploaded messages slated for posthumous release, and from which editing access to at least a subset of said uploaded messages is accessible to the subject user for user-reconfiguration of said collection;(iii) further presentation to the subject user, in step (b) after plotting at least a subset of the timeline-based messages, a message editor through which a selected one or more of the timeline-based messages are convertible into another scheduled release by user-triggered assignment of newly assigned scheduling data to the selected one or more of the timeline-based messages; and(iv) calculation of the timeline intervals in dependent relation to a total uploadedquantity of said timeline messages and a currently assigned duration of the timeline.

42. One or more non-transitory computer readable media having stored therein computer executable code configured to, when executed, perform steps (a) and (b) of any preceding claim.

Images