This application claims priority to U.S. Provisional Patent Application No. 62/017,990 filed on Jun. 27, 2014, the entire disclosure of which is incorporated by reference as though fully set forth herein.
This present invention relates to systems and methods for organizing and distributing digital data. More specifically, the present invention relates to systems and methods for optimizing the efficiency of organizing and distributing digital data via network systems.
The use of social networks across the general population has increased dramatically in recent years. A corresponding need has arisen for efficient methods and techniques for creating custom social networks designed for distribution of digital content via a permission based folder management and repository curation system. Typically, a user utilizes listed methods to create groups of contacts for the purpose of selectively distributing uploaded digital content according to determined permission access, and to create different forms of software applications available through web, native desktop OS' (Windows 7/8, Mac OS X, etc.), and mobile OS's (iOS, Android, Windows Phone) sources. Improved methods are needed which allow restriction of access to either entire sub-application utilities inside the created organization network, or specific content contained within.
Creating software applications is cost intensive, while creating websites has become trivial. Small and medium sized businesses or groups are able to create quality web presences for little investment contrasted with development requirements for web, desktop, and mobile applications. While websites are great options to display static information, increasingly digital business practices world-wide call for interactive software connecting leaders to constituents, businesses to customers, and managers to employees.
Mobile devices have brought resurgence in native application software. Native software, found locally on an electronic device (as opposed to through a web browser), provides a level of quality and responsiveness as yet unmatched by web counterparts. The ability to have these forms of applications developed in conjunction with a web presence exponentially increases costs and development complexities. Accordingly, less complex and costly methods for developing such applications are needed.
The methods of the present invention solve the problem of an organization having to create its own suite of mobile, desktop, and online applications for private collaboration, communications, and distribution of digital assets. The organization does not have to solve problems related to application design, development, security, and deployment.
Selected embodiments of the present invention will now be explained with reference to the accompanying figures. It will be apparent to those skilled in the art from this disclosure that the following descriptions are provided for illustration only and not for the purpose of limiting the invention as defined by the appended claims and the equivalents. Particular embodiments described herein provide a more appealing technical environment for sharing business unit or organization related material. In this environment, individuals who join the network organization may access material and functionalities as set forth by the network administrators. The different roles and duties that make up an organization are reflected in their interfaces capabilities of the network.
Preferably, the technical environment is accessed through native desktop, mobile, tablet, and web based applications, and the users are members of a system providing them enrollment access to their associated business' organization network. The deployment of this organization network is made possible by selections made during organization network creation, yielding varying sub-applications and navigational structures for the type of business or organization declared. An accounting firm would have an inherently different feature set than a legal office. The organization network administrators control the functionalities available to each of their members and the members' system users, thus dramatically impacting the individual user's interface and perceived system functionality for his or her individual embodiment. The resulting structure of the network created for the user's organization is responsive to the information provided by the organization's user.
The organizational network is generally defined by the roles different members of the organization play, and by the utility the network provides. An organizational network may be represented by a tree structure. Each node of the tree defines either contact hierarchies or sub-application order. Connections between contacts and sub-applications relate to access and different forms of interaction.
The application server 200 manages the plurality of databases 150 including but not limited to a user database 210, an organizations database 220, a navigation database 230, and an associations database 240. The user database 210 contains account and profile information for each of the member organizations and/or users who have registered with the service managed by the computer system. The profile information may include, among other things contact information such as: a unique user identifier, names, telephone numbers, email addresses, social media usernames, physical locations and descriptions, digital art, assets, organizational multi media assets, and other common organizational information or combinations of the foregoing.
The organizations database 220 stores information relating to the sub-networks created on the system. This information may include a unique network identifier, member profile information, digital data assets, subscription information, access request structures, and permission structure, among other things. This information also includes ORGANIZATION, NAVIGATION, ASSOCIATION, VISIBILITY, and INTERACTION preferences, the uses of which are described below in greater detail in connection with databases 230 & 240, and as illustrated in the flow diagrams of
The navigations database 230 stores structural information that helps build the sub-networks (also referred to as an organization network) deployed on the system. This information may include, by way of example and not of limitation: organization types, section architecture structures, contact folder hierarchies, default permission sets, imparted organizational requirements, and user interface (“UI”) presets.
The associations database 240 stores information relating to inter-sub-network communication and hand-shaking; which is a technical term describing the process by which two devices initiate communication with one another and establish a communication protocol. This information may include, among other things, relationship maps between existing organizations, sub-network organization requirements, and application to sub-network organization password information.
The contents of the user database 210, the organizations database 220, the navigations database 230, and the associations database 240 are updated as needed. The updates reflect informational inputs related to new users, organizations, navigations, and associations and edits of existing information made through computers 400.
Referring now to for
In Step 202, the application server 200 (
Returning to
At Step 204, U1 sets NAVIGATION, ASSOCIATION, and DEPLOYMENT preferences for the information entered in Step 203. As the three identifiers suggest, the NAVIGATION, ASSOCIATION, and DEPLOYMENT preferences refer, respectively, to the flow of information within the ensuing organizational network, the flow of information to other organization networks, and the flow of information to members. As further described below in conjunction with the interface illustrated in
For certain embodiments, the information collected to create network organizations may be subdivided into different interfaces. Accordingly, after Step 205, U1 may repeat Steps 202 through 204 for additional preferences and information groups, as required by organization characteristics.
At Steps 206 and 207, the application server 200 identifies and builds ON1's navigational architecture and permissions structure from selected NAVIGATION and DEPLOYMENT preferences, respectively. This information is written to database 220 of system 100.
At Step 208, the application server determines if U1 declared an association with an existing parent organization on the network (ON2), an exemplary purpose being a business unit attempting to integrate with the parent company. In an embodiment, before updating the databases 220 and 240, the other organization network is required to confirm a request for network amalgamation to reflect organizational pairing. Doing so prevents ON1 from falsely claiming that the organizations are linked when they are, in fact, not. Delivery of ON1's request is made via the application server to ON2 in Step 209.
At Step 210, the application server 200 updates the databases 210 and 220 to reflect to association between U1 with ON1. At this point, the new organizational network has been created and the user can log in.
At Steps 211 through 214, the result of the request in Step 209 to ON2 is handled. and the databases 220 and 240 are updated. If the request is denied, Step 212 will notify ON1 of the declined association. Steps 213 and 214 rely on ON2's acceptance of ON1's request. Step 213 injects additional digital navigation paths, permissions, and digital assets to enable ON1 to send information to the parent ON2. Step 214, the application server ties ON1 with ON2.
As those skilled in the art will recognize, once ON1 has been created, U1 may create additional organizational networks or add additional organizational network associations at any time using the operations described above. Now that ON1 is on the system, additional operations will allow U1, and future ON1 members, depending on permissions level, which will be discussed in greater detail below with respect to
In Step 303, the application server 200 responds to a request from a registered user (U1) to create a contact that will not be associated with the system 100. This would merely be a contact card on the system with no associated member.
At Step 304, the application server verifies current business requirements for organizational networks on the current system embodiment. Parallel systems may not require sub-organizations to maintain license seats. Step 304 ensures required licensing standards are met by ON1. Should a system license be requested, Steps 305 and 306 provide for licensing registration. These Steps may be repeated during future contact association requests if Step 304 calls ON1 to satisfy licensing requirements.
At Step 307, the application server places a hold on a license seat as the contact invitation request enters an outbound stage. At Step 308, the server determines if the contact information of U2 exists within database 210. Optimally, U2 would be found on the system, with Step 309 creating a profile representative of this fact via updating database 220.
In steps 310, 311, 312, 313, and 314, the opposite result of Step 309's request to database 210 is handled, and the databases 210 and 220 are updated. Step 310 creates a profile representative of U2 not being on the service, while being invited to ON1. Step 311 creates a temporary profile for U2, allowing the application server to deliver an organization request in Step 312. Both actions are completed via updates to database 210. At Step 313, the application server 200 sends an electronic request to U2's contact information.
In an embodiment, Step 314 is completed by U2 accepting ON1's network association invitation through creating an account. In Step 315, the application server would convert the profile information in databases 210 and 220 from Steps 310 and 311 to reflect U2's active profile state on the system. Unfortunately, not all invitations are received or acted upon in Steps 316 and 317, associated license holds are released, and databases 210 and 220 are updated.
In Step 318 U2 is made aware of ON1's pending network invitation. As further described below in conjunction with
In an embodiment, Step 319 would be completed by U2 accepting the invitation of ON1. In Step 320, the application server would update database 210 and database 220, creating communications conductivity between U2 and ON1. As those skilled in the art will recognize, once U2 has been associated with ON1, U2 may interact with the organizational network using network operations.
Not all invitations are accepted. In Steps 321 and 322, associated license holds are released, and databases 210 and 220 are updated to reflect invitation rejection.
For some embodiments, the information presented to inform network organization requests and obligations may be subdivided into different interfaces. Accordingly, after Step 318, U2 may repeat Steps 318 through 204 for additional preferences and information groups, as required by organization characteristics.
Referring now to
In Steps 403 and 404, the application server responds to AU's request by providing AU with an interface to enter identifying information and corresponding permission settings for CG and DF, respectively.
At Step 405, AU enters the information in the fields provided by the interface in Step 403. As illustrated,
At Step 406, AU enters the information in the fields provided by the interface in Step 404. As more clearly illustrated in
In Steps 407 and 408, AU sets VISIBILITY preferences for the information entered in Steps 405 and 406. Additionally, AU sets INTERACTION preferences for Step 405. As the two identifiers suggest, the VISIBILITY and INTERACTION preferences refer respectively, to the flow of sub-application availability and contents to OMs residing in CG's and to what extent OMs can interact with sub-application functionalities. The VISIBILITY setting for CG's are equal to the VISIBILITY selections for DF's; a change in CG visibility preferences will be reflected in the visibility preferences of DF for which the adjustment concerned. The INTERACTION preference, however, can only be set from CG to DF. Changes within DF VISIBILITY preferences will never inflict change upon a CG's associated INTERACTION preference.
At Step 409, the application server 200 updates the database 220 to reflect the new relations between CG's and DF's.
At Step 410, the application interface adds or removes functional elements as per the Step 409's changes to the database 220. As those skilled in the art will recognize, once AU has adjusted the CF of associated OMs, their interface will either present or hide network sub-applications and their associated functionalities. Changes in a CF can restrict content found in DF's, and the ability to use the DF's computational attributes.
Steps 411 and 412 allow AU to adjust the aforementioned preferences. For some embodiments, VISIBILITY and INTERACTION may be adjusted without collecting the groups of information, allowing editing of preferences only.
Referring now to
While only selected embodiments have been chosen to illustrate the present invention, it will be apparent to those skilled in the art from this disclosure that various changes and modifications can be made herein without departing from the scope of the invention as defined in the appended claims. Furthermore, the foregoing descriptions of the embodiments according to the present invention are provided by illustration only and not for the purpose of limitation.
| Number | Date | Country | |
|---|---|---|---|
| 62017990 | Jun 2014 | US |