Network of nodes using delta processing

Abstract

To provide systems, methods, and computer readable media for managing a network of nodes with delta processing.SOLUTION: A method includes storing a network with multiple connected nodes. The multiple nodes represent entities of the network. The method also includes receiving one or more deltas to the network that indicate updates to the connections among the multiple nodes. The deltas can be added to a queue. The connections between the nodes of the network can be updated using a delta from the queue. The network can be processed after updating the connections between the nodes to generate a vector for a given node. One or more paths for the given node can be identified based on the generated vector.SELECTED DRAWING: Figure 15

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. patent application Ser. No. 15 / 966,439, filed April 30, 2018, the disclosure of which is incorporated herein by reference.

[0002] Field SUMMARY OF THE DISCLOSURE Embodiments of the present disclosure relate to managing a network of nodes using delta processing that provides efficient graph analysis. [Background technology]

[0003] background In recent years, social networks have demonstrated the utility of connectivity. Large networks of connected nodes can enable participating entities to identify new opportunities, whether those opportunities are new friendships, business contacts, or other useful connections. These networks also have the potential to unearth hidden synergies between groups of connected nodes. However, the benefits of connected nodes are not without risks. Large networks such as social networks are plagued by issues related to data privacy, identity management, and other data sharing concerns. Additionally, due to the dynamic nature of connectivity, performing data analytics on connected nodes can pose unique computational challenges. Summary of the Invention [Means for solving the problem]

[0004] overview SUMMARY OF THE DISCLOSURE Embodiments of the present disclosure are directed to systems and methods for managing a network of nodes using delta processing that provide substantial improvements over the related art.

[0005] A network comprising a plurality of connected nodes may be stored, the plurality of nodes representing entities of the network. One or more deltas for the network may be received indicating updates to connections between the plurality of nodes. The deltas may be added to a queue. Connections between nodes of the network may be updated using the deltas from the queue. The network may be processed after updating connections between the nodes to generate a vector for a given node. One or more paths for the given node may be identified based on the generated vector.

[0006] Features and advantages of the embodiments will be set forth in the description that follows, or will be obvious from the description, or may be learned by practice of the disclosure.

[0007] Further embodiments, details, advantages and modifications will become apparent from the following detailed description of the preferred embodiments, which should be taken in conjunction with the accompanying drawings. [Brief description of the drawings]

[0008] [Figure 1] FIG. 1 illustrates a system for managing data processing for a network of nodes in accordance with an exemplary embodiment.

[0009] [Diagram 2] FIG. 2 illustrates a block diagram of a computing device operatively coupled to a network data management system according to an illustrative embodiment.

[0010] [Diagram 3] FIG. 2 illustrates a functional diagram for managing data processing for a network of nodes in accordance with an exemplary embodiment.

[0011] [Figure 4] FIG. 2 illustrates a graph representing a network of nodes in accordance with an example embodiment;

[0012] [Diagram 5] FIG. 2 illustrates a relational data table for network data processing according to an exemplary embodiment.

[0013] [Figure 6] FIG. 1 illustrates a flow diagram for delta processing for a network of nodes in accordance with an exemplary embodiment.

[0014] [Figure 7] FIG. 2 illustrates a functional diagram for secure management of data processing for a network of nodes according to an exemplary embodiment.

[0015] [Figure 8] FIG. 2 illustrates an example graphical user interface for configuring a view of a network of nodes according to an example embodiment.

[0016] [Figure 9] FIG. 2 illustrates a pie chart view of network data according to an example embodiment.

[0017] [Figure 10] FIG. 2 illustrates a table view of network data according to an example embodiment.

[0018] [Figure 11] FIG. 2 illustrates a network graph view of network data according to an example embodiment.

[0019] [Figure 12] FIG. 1 illustrates a global view of a supply chain in accordance with an illustrative embodiment;

[0020] [Figure 13] FIG. 11 is an illustration of an other world view of supply chain data in accordance with an illustrative embodiment.

[0021] [Figure 14] FIG. 11 illustrates another world view of a supply chain in accordance with an illustrative embodiment;

[0022] [Figure 15] FIG. 1 illustrates an example method for managing a network of nodes using delta processing in accordance with an example embodiment.

[0023] [Figure 16] FIG. 1 illustrates an example method for providing secure data management for a network of nodes in accordance with an example embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0024] Detailed Description An embodiment manages data processing for a network of nodes. An exemplary network may include multiple nodes with multiple connections between the nodes. In some embodiments, the network may be a social network with various degrees of information sharing. From time to time, a new connection may be created between two nodes that were not previously connected, or a connection may be severed between nodes that were previously connected. Based on the current configuration of the network (e.g., the current connections between the nodes, etc.), one or more paths may be identified. For example, a path may start at a first node and proceed through a second, third, and fourth node before terminating at a fifth node. Such identified paths may be useful for identifying patterns, trends, or risks, or for making predictions, or for other analytical purposes (i.e., depending on the nodes in the network and the particular embodiment).

[0025] However, the dynamic nature of these networks introduces risks and computational challenges. For example, social networks are often changing, establishing new node connections and tearing down old ones. Therefore, identifying paths between nodes can be computationally intensive. As further detailed herein, embodiments leverage drip-feed delta processing to manage the networks to achieve computational efficiency while maintaining dynamic update capabilities.

[0026] In addition, information sharing may be difficult in networks that contain confidential or other sensitive information. In some embodiments, node connections may be further defined to characterize relationships between nodes (e.g., suppliers, customers, potential suppliers, potential customers, social connections, etc.). In these examples, information shared by a given node in the network may be tailored based on connection type, distance from a given node in the network, and customer preferences for the given node. Embodiments include security protocols to ensure user-specific data retrieval in accordance with these information sharing policies.

[0027] In some embodiments, nodes in the network may represent suppliers, intermediaries, and / or customers in a supply chain. For example, connections between nodes may represent various relationships between these entities. A path may represent an extended relationship between multiple entities. For example, a path of multiple nodes connected by supplier / customer relationships may represent a supply chain for a commodity or product.

[0028] Such a network may also be referred to as a graph based on the connections between the nodes. Traversing this graph may be useful, for example, to identify links in a supply chain, potential links that may be used to adjust the supply chain, risks to the supply chain (geographical risks, political risks, weather risks, etc.), and for other useful purposes. However, traversing a graph representing a network of nodes may pose certain computational challenges due to the dynamic nature of some of these networks (e.g., social networks, etc.), such as frequent changes among connections between nodes.

[0029] Embodiments provide a pre-computation solution and a drip-feed delta that aggregates change records in a queue. Upon updating data in the network based on queued change records (e.g., drips), the graph may be processed to generate multiple direct access vectors for nodes of the graph. Embodiments include maintaining a pre-computed version of the network data that can efficiently retrieve data related to graph traversals. For example, the direct access vector of a given node indicates one or more potential paths that include the given node. In some embodiments, the graph processing / pre-computation solution may include determining a transitive closure.

[0030] The pre-computed solution and / or the generated direct access vectors can then be used to efficiently traverse the graph. For example, in the described supply chain embodiment, the paths can be supply chains, potential supply chains, or other relationships between customers and suppliers, and one or more paths can be identified for a given node based on the node's direct access vectors. In various embodiments, the drip-feed deltas and pre-computed solution maintain a graph (e.g., a social network) readily available for efficient traversal.

[0031] In some embodiments, entities (e.g., nodes) of the network may have authorized users that interact with the system. For example, authorized users may edit profiles for the entity, send messages to other entities of the network, modify relationships with other entities, retrieve data related to the entities of the network, perform network analysis and other suitable functions. However, in some embodiments, confidential or sensitive information for one or more entities may be stored in association with the network (e.g., in a data store). For example, in a social network, the system may store sensitive information for a first entity that may be shared with a subset of other entities but not with the remaining entities. In other examples, the sensitive information may be marked as private and therefore may not be shared with any other entities of the social network.

[0032] In some embodiments, the system can provide secure data retrieval for entities of the network. For example, a security subsystem can maintain one or more permissions for authorized users and determine what information the users can retrieve. Based on the security subsystem, data retrieval requests can be filtered to ensure that authorized users are provided only with information that complies with the established permissions. For example, relationship filtering can be used to filter queries generated according to the permissions before performing a search in a data store. In another example, data redaction can be performed on data retrieved by a query according to the permissions to redact the data before providing it to authorized users. The security subsystem, relationship filtering and data redaction can be used to ensure secure data management of sensitive or confidential data for entities of the network.

[0033] In embodiments where nodes in the network represent suppliers, intermediaries, and / or customers in a supply chain, secure data management may be used to provide supply chain information to entities in the network. For example, permissions in the security subsystem may be set based on paths of nodes in a graph representing the network. Because the paths represent a supply chain, entities on a given path may be given permission to retrieve relevant data for the supply chain and analyze the results. In embodiments, graphical user interfaces are displayed that include supply chain information based on the graph that is traversed and the data that is retrieved and secured. These graphical user interfaces may be useful for identifying risks to the supply chain, analyzing the efficiency of the supply chain, and other purposes.

[0034] Currently, the retail supply chain market is made up of millions of companies from field to fork. Often these different companies have different systems and practices to manage product development, sourcing, compliance, ordering, shipping, quality control, inventory, forecasting, replenishment, etc. The industry is often unable to achieve traceability due to the complexity, selection and performance of the entire supply chain and the sheer number of disastrous systems (especially for certain perishable goods such as food, or other goods that impact health). Integrations and APIs are limited in scope and hundreds of silos have been created. The new wave of transparency solutions and trading networks only adds yet other silos as they compete with their own supply chain community.

[0035] Embodiments allow various systems, micro-applications, Internet of Things ("IoT") and smart devices (controlled by registration via an app store principle) to communicate a common set of data, transactional key performance indicators (KPIs) and data links with each other. The central environment provides a platform that allows retailers to exchange data across a host of processes regardless of system, provides the supply chain with the ability to reuse a common set of data, increases efficiency, and provides a data link that allows the flow of data across end-to-end processes. Embodiments can connect communities, for example, through social networking capabilities. Adoption is facilitated by providing an efficient platform and services for managing multiple systems and data feeds, for example, from one dashboard.

[0036] Such a selection can lead to many benefits: Reduction of duplication leads to significant efficiency gains and improved data quality across the supply chain; Central reporting, visualization and monitoring of transactions across the supply chain increases efficiency, improves speed of response, allows risk prediction and provides essential traceability to events that increase risk or cause disruptions, for example; Data links enable different solutions to communicate in the course of business, improving satisfaction, user experience and quality; Open connectivity can facilitate application or equipment selection, inspire innovation, motivate adoption and be adapted to vast capabilities across the globe.

[0037] Reference will now be made in detail to the embodiments of the present disclosure, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. However, it will be apparent to those skilled in the art that the present disclosure may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the embodiments. Wherever possible, like reference numerals are used to refer to like elements.

[0038] 1 illustrates a system for managing data processing for a network of nodes, according to an example embodiment. System 100 includes client device 102, cloud server 104, authentication server 106, load balancer 108, user interface logic 110, stateless business services layer 112, data access layer 114, security policy 116, and database 118. Client device 102 may be a computing device such as a desktop, laptop, tablet device, mobile phone, etc. For example, client device 102 may be any computing device similar to system 210. In some embodiments, client device 102 may execute applications (e.g., locally stored applications, web-based applications, etc.) that communicate with cloud server 104 to access software services for the network of nodes.

[0039] For example, the client application may be implemented using one or more web technologies (e.g., HyperText Markup Language ("HTML") 5.0, JavaScript, cascading style sheets (CSS), scalable vector graphics ("SVG"), etc.). Such applications may be viewed from both standard and mobile browsers using desktop or mobile devices. In some embodiments, a downloadable mobile application (e.g., iOS, Android, etc.) may be developed. For example, the downloadable application may be a container application that uses a "control-less" browser internally (e.g., using Cordova technology) to display a website. In various embodiments, Thus, the user experience with the application is consistent when using a standard browser (e.g., desktop), a mobile browser, a downloadable application, or any other suitable configuration. Exemplary communications sent to and received from a client device 102 may include invitations, network messages, network-related data, and other material pertaining to the network.

[0040] Cloud server 104 may be a server suitable for hosting a cloud-based software services platform for a network of nodes. For example, cloud server 104 may be any computing device similar to system 210 and / or ... The present invention may include various modules of an engagement engine ("EE") that are embedded in an operating system, web technologies such as Oracle® Java® Enterprise Edition ("EE"), or other suitable components.

[0041] In some embodiments, the cloud server 104 is in communication with an authentication server 106, a load balancer 108, and a UI logic 110. For example, a user of one of the client devices 102 may be authenticated by the authentication server 106. The authenticated user may then be associated with an identity in an identity management service. An example of an authentication server 106 is Oracle® Identity Cloud Service ("IDCS"). The user may then access network application services based on the user's authenticated identity.

[0042] The load balancer 108 may be a server or a module that distributes load across one or more processors (or one or more computing devices) to effectively manage the computational resources of the system. The load balancer 108 may be any computing device similar to the system 210.

[0043] The UI logic 110 may be a server or a module including software for presenting a user interface to one or more client devices 102. For example, the UI logic 110 may communicate with an application executing on one of the client devices 102 to present an interface for interacting with software services for the network of nodes. The UI logic 110 may configure one of the client devices 102 to display the various graphical user interfaces disclosed herein.

[0044] The stateless business services layer 112 can provide stateless software services for a network of nodes. For example, one or more microservices can be defined to securely retrieve, update, or write network data, traverse the network, send messages to participants in the network, etc. These stateless microservices are described further herein.

[0045] The data access layer 114 may be a software layer that performs data processing functions such as query generation. For example, based on a request from the stateless business services layer 112, one or more requests, instructions, or updates related to stored network data may be received at the data access layer 114. The queries or instructions may be generated based on the received request (e.g., a structured query language ("SQL") query) and / or a database. The data may be generated for source 118.

[0046] The security policy layer 116 may be a software layer that protects data retrievals, updates, or commands to the database 118 according to stored security policies. For example, the database 118 may be any suitable database (e.g., an Oracle® relational database) for storing network data. The network data may include confidential or sensitive information for participants of the network. Updates, commands (e.g., writes to the database), or attempts to retrieve (e.g., queries) from the data access layer 114 may be processed by the security policy layer 116 to filter the network data according to the stored security policies.

[0047] In some embodiments, the cloud servers 104, authentication servers 106, load balancers 108, user interface logic 110, stateless business services layer 112, data access layer 114, security policies 116, and database 118 may be integrated into a single system or computing device, distributed across various computing devices, and in some embodiments, distributed across various locations, or combinations thereof may be configured in any other suitable manner. In an exemplary embodiment, the cloud servers 104, authentication servers 106, load balancers 108, user interface logic 110, stateless business services layer 112, data access layer 114, security policies 116, and database 118 may be software, hardware, or a combination thereof.

[0048] Figure 2 is a block diagram of a computer server / system 210, according to an embodiment. As shown in Figure 2, the system 210 may include a bus device 212 and / or other communication mechanism(s) configured to communicate information between various components of the system 210, such as a processor 222 and a memory 214. In addition, the communication device 220 may enable a connection between the processor 222 and other devices by encoding data that is transmitted from the processor 222 to another device over a network (not shown) and decoding data that is received from the other system over the network for the processor 222.

[0049] For example, the communication device 220 may include a network interface card configured to provide wireless network communication. Various wireless communication technologies may be used, including Wi-Fi and / or cellular communications. , the communications device 220 may be configured to provide a wired network connection(s), such as an Ethernet connection.

[0050] Processor 222 may include one or more general-purpose or special-purpose processors for performing the computational and control functions of system 210. Processor 222 may include a single integrated circuit, such as a microprocessing device, or may include multiple integrated circuit devices and / or circuit boards that operate in cooperation to achieve the functions of processor 222. Additionally, processor 222 may execute computer programs, such as operating system 215, network manager 216, and other applications 218, that are stored in memory 214.

[0051] The system 210 may include a memory 214 for storing information and instructions for execution by the processor 222. The memory 214 may include various components for retrieving, presenting, modifying, and storing data. For example, the memory 214 may store software modules that provide functionality when executed by the processor 222. The modules may include an operating system 215 that provides operating system functionality for the system 210. The modules may include the operating system 215, a network manager 216 configured to manage data processing for the network, and other application modules 218. The operating system 215 provides operating system functionality for the system 210. The network manager 216 may include one or more APIs that enable system calls for data processing related to the network, or may further provide any other functionality of the present disclosure. In some examples, the network manager 216 may be implemented as an in-memory configuration.

[0052] The non-transitory memory 214 may include a variety of computer-readable media that may be accessed by the processor 222. For example, the memory 214 may be any type of memory, including random access memory ("RAM"), dynamic RAM ("DRAM"), static RAM ("SRAM"), read-only memory ("RRAM"), or the like. The non-transitory computer-readable medium may include any combination of read only memory, flash memory, cache memory, and / or any other type of non-transitory computer-readable medium.

[0053] The processor 222 is further coupled to a display 224, such as a Liquid Crystal Display ("LCD"), via the bus 212. A keyboard 226 and a cursor control device 228, such as a computer mouse, are further coupled to the communication device 212 to allow a user to interface with the system 210.

[0054] In some embodiments, the system 210 may be part of a larger system. Thus, the system 210 may include one or more additional functional modules 218 that include additional functionality. Other application modules 218 may include various modules of an engagement engine ("EE"), for example, embedded in the Oracle® Cloud. A database 217 is coupled to the bus 212 and provides aggregated storage for the modules 216 and 218, for example, storing wireless device usage, and in some embodiments, storing user profiles, transaction histories, etc. The database 217 may store data in an integrated collection of logically related records or files. The database 217 may be an operational database, an analytical database, a data warehouse, a distributed database, an end-user database, an external database, a navigational database, an in-memory database, a document-oriented database, a real-time database, a relational database, an object-oriented database, an HFDS, or any other database known in the art.

[0055] Although shown as a single system, the functionality of system 210 may be implemented as a distributed system. For example, memory 214 and processor 222 may be distributed across several different computers that collectively represent system 210. In some embodiments, system 210 may be part of a device (e.g., a smartphone, a tablet, a computer, etc.).

[0056] In some embodiments, system 210 may be separate from a device and may remotely provide the described functionality to that device. Additionally, one or more components of system 210 may not be included. For example, in function as a user or consumer device, system 210 may be a smartphone or other wireless device that includes a processor, memory, and display, but does not include one or more of the other components shown in FIG. 2, and may include additional components not shown in FIG. 2.

[0057] FIG. 3 illustrates a functional diagram for managing data processing for a network of nodes according to an exemplary embodiment. Diagram 300 illustrates an example of an exemplary software framework that can provide services to users of the network. FIG. 3 includes an Application Development Framework ("ADF") interface 302, an ADF task flow 304, beans 306, a data model 308, services 310, a data platform 312, a security platform 314, data storage 316, and an Extensible Markup Language ("XML") definition 318.

[0058] The ADF face 302 may be a view portion of a software framework that includes HTML, CSS, and any other suitable code for providing a user interface. One or more of the graphical user interfaces disclosed herein may be provided by the ADF face 302. The ADF task flows 304 may be used to construct one or more user interface elements to perform software functions. The beans 306 may provide model layer business logic rules for user interface logic and integration. The ADF task flows 304 and the beans 306 may be a controller portion of a software framework. For example, the ADF task flow 304 may sit on top of the beans 306 and implement a framework for client pages. In some embodiments, the ADF task flow 304 may provide a set of task flow constructs that may be used to manage a user's journey through a collection of application screens. One or more functions of the elements of the graphical user interfaces disclosed herein may be provided by the ADF task flows 304 and / or the beans 306.

[0059] The data model 308 can be the model portion of the software framework. The data model 308 can provide business logic rules and structure for interfacing between the user interfaces (e.g., views and controllers) and the software services (e.g., the business services portion of the software framework). The services 310 can be the business services portion of the software framework. The services 310 can provide the business rules, logic, enablement, and structure that allows software services to operate on, for example, stored network data. The services 310 can include one or more of the microservices disclosed herein.

[0060] The data platform 310, the security platform 314, and the data storage 316 may be the data services portion of the software framework. The data platform 312 may map logical data to physical storage. For example, based on a request from the service layer 310, the data platform layer 312 may generate data instructions (e.g., queries, change requests, etc.) to retrieve, store, or modify data stored in the data storage 316. These data instructions are protected by the security platform 312. The security platform 312 may store security policies used to filter data instructions from the data platform layer 312. In this manner, data stored in the data storage 316 is security by the security platform 312. The data platform 312 and the security platform 314 may be defined by an XML definition 318. Therefore, these software components are agile because they may be immediately updated and / or rebuilt by updating the XML definition 318. The services 310, the data platform 310, the security platform 314, and the data storage 316 are further described with reference to FIG. 7.

[0061] Referring again to FIG. 1, in some embodiments, system 100 can provide software services to a network of nodes represented by a graph. FIG. 4 shows a graph representing a network of nodes according to an example embodiment. Graph 400 can represent a network of multiple nodes 402 and multiple connections 404. Each node 402 can represent an entity that participates in the graph / network, and each connection 404 can represent a relationship between the entities. In some embodiments, graph 400 is a directed acyclic graph ("DAG"), or any other graph suitable for representing a network (e.g., a social network).

[0062] In some embodiments, the system 100 of FIG. 1 can provide software services to the network represented by the graph 400. For example, the nodes 402 can each represent an organization, and users affiliated with these organizations can access the network using one of the client devices 102. These users can communicate with the cloud hosting server 104 and the rest of the system 100 to access, operate, or interact with the network of nodes. For example, the user's identity is authenticated by the authentication server 106 (e.g., an IDCS service, or any other suitable identity management service), and the user can then interact with the network according to the permissions associated with his or her authenticated identity.

[0063] In some embodiments, each organization represented by node 402 can register with the network. A profile can be stored for the registered organization, which can include, for example, one or more of the name, address or location (e.g., latitude, longitude, home country, and any other suitable location information), branding associated with the organization, a home page Uniform Resource Locator ("URL"), social media accounts for the organization, combinations thereof, and other suitable information.

[0064] In an embodiment, the network of nodes may represent a network of suppliers, customers, and / or intermediaries. In such an example, the organizational profile may also include one or more of products sold, products purchased, certificates from third party organizations, expired certificates from third party organizations, direct suppliers (e.g., from among other entities in the network), direct customers (e.g., from among other entities in the network), instructions (e.g., recipes) for goods or products, parts (e.g., ingredients) for goods or products, combinations thereof, and any other suitable information for buyers or sellers of products or goods.

[0065] In some embodiments, the certification from a third party includes food or drug safety certification (e.g., Halal certification, Kosher certification), Fair Trade certification, certification from one or more known certification entities (e.g., Global Food Safety Initiative ("GFSI"), British Retail Consortium ("BRC"), Food and Drug Administration ("FDA"), United States Department of Agriculture ("USDA"), Marine Stewardship Council ("MSC"), Safe Quality Food Institute ("SQF"), Hazard Analysis and Critical Control Points ("HACCP") certification, etc. These certifications often require renewal, and therefore, certifications may expire from time to time. Expired certifications may create potential issues in the supply chain depending on the ultimate destination for the goods or products (e.g., destination country and local regulations).

[0066] In some embodiments, a product or procedure includes a recipe, or a list of ingredients used to make the product or commodity. For example, product A may include one or more recipes, such as recipe B, which lists ingredients C, D, E, and F. An exemplary product or commodity may be fruit juice. A given organization may be considered another customer if the organization has a recipe for a product such as fruit juice. Ingredients in fruit juice may be fruit concentrates (e.g., cranberry, apple, etc.), different types of fruit, and other suitable ingredients. A given organization may be considered a supplier if the organization has ingredients for another organization's recipe.

[0067] Once registered, organizations can interact with one another in the network: for example, organizations represented by nodes 402 can send messages to one another, create posts that can be shared, "like" posts from other organizations, send invitations to other organizations to join the network, and perform other functions suitable for a social network.

[0068] In some embodiments, one or more paths between the nodes 402 in the graph 400 may be identified based on the connections 404. For example, the path 406 may include four of the nodes 402 as shown in FIG. 4. In embodiments in which the nodes 402 represent entities that may be customers, suppliers, and intermediaries for transactions involving goods or products, the path 406 may represent a supply chain. For example, the path 406 may represent a flow of goods or products between the nodes 402 that ends at an end point (e.g., a customer). In some embodiments, the end point may be one of the nodes 402 that represents an entity in the supply chain that requests information. For example, the node 402 that represents an end point of the path 406 may request information about the flow of goods or products from the entity that represents the node. In some examples, the path 406 may represent a supply chain for an entity, although this end point may be an intermediary because the entity may sell goods or products to a downstream customer. Authorized users (eg, authenticated identities) of the entity can interact with software services on the network and retrieve this supply chain information, as described in further detail below.

[0069] In some embodiments, a connection 404 can represent a business relationship between organizations (e.g., a customer and a supplier). For example, organization A can invite organization B to become one of its suppliers and / or organization B can invite organization A to become one of its customers. This can happen when organization B has an ingredient for one of organization A's recipes. Within a network, a connection 404 between organization A and organization B can be created when a business relationship invitation is sent from one of the organizations and accepted by the other.

[0070] In one embodiment, once two organizations have sent and received an invitation to enter into a trading relationship, they can identify which recipes and ingredients depend on this relationship. The customer organization can attribute some of the ingredients used in its recipes to the new supplier organization. Similarly, the supplier organization can attribute recipes for products it supplies to the name of the customer organization. With reference to FIG. 4, when connections 404 represent trading relationships, graph 400 shows the potential flow of goods between trading organizations (e.g., a supply chain). For example, if a supplier organization has at least one product recipe associated with the customer organization, and the customer organization has a recipe that includes at least one ingredient associated with the supplier organization, the supplier organization is shown in (is considered part of) the customer organization's supply chain.

[0071] In some embodiments, the connection 404 can represent a (non-transactional) social relationship. For example, organization A can submit a social connection request to organization B, and a connection 404 representing the social connection can be formed.

[0072] In some embodiments, the network data may be mapped onto multiple relational data tables in a relational database. FIG. 5 illustrates relational data tables for processing of network data according to an exemplary embodiment. The exemplary data tables illustrated in FIG. 5 include Organization 502, Connection 504, Recipe 506, Ingredient 508, Recipe_Ingredient 510, Recipe_Consumer 512, and Ingredient_Supplier 514. The data tables may include attributes (e.g., ID, name, etc.) and, in some examples, key information (e.g., primary and foreign keys). The illustrated data schema is simplified for purposes of this disclosure, and data schemas for network data may be implemented to be substantially larger than the illustrated example. Other suitable schemas may also be implemented.

[0073] In some embodiments, organizations 502 can store organization profile information, such as an organization ID, a name, other profile information detailed herein, and any other suitable organization profile information. Connections 504 can store information about connections between nodes, such as a connection ID, a consumption ID (e.g., a customer ID), a production ID (e.g., a supplier ID), and any other suitable connection information. In some embodiments, connections between nodes can be based on materialized flows of goods or products (e.g., materialized supplier / customer relationships).

[0074] In some embodiments, recipes 506 can store recipe information such as a recipe ID, a recipe description, an owner organization ID, and any other suitable recipe information. Similarly, ingredients 508 can store ingredient information such as an ingredient ID, an ingredient description, an owner organization ID, and any other suitable ingredient information. Recipes_ingredients 510 can store recipes that are owned and ingredients that are owned by the owner. The association between the ingredient and the product can be stored.

[0075] In some embodiments, recipe_consumer 512 can store information associating a recipe with a connection that consumes the recipe, such as a connection between organizations represented by a connection ID stored in connection 504. Similarly, ingredient_supplier 514 can store information about ingredients and the connections that supply the ingredients. For example, recipe_consumer 512 and ingredient_supplier 514 can be used to determine how the organizations from a given connection are connected (e.g., what recipe / ingredient business relationships exist between them).

[0076] For example, recipe A owned by a first organization may include ingredients B, C, and D. An ingredient owned by a second organization may include ingredients D, E, and F. A potential flow of goods or products exists between the first organization and the second organization because the first organization owns a recipe that includes an ingredient owned by the second organization, i.e., ingredient D. In some examples, a business relationship may be identified by the first organization and the second organization, thereby forming a connection (having a connection ID). Once connected, the first organization may associate recipe A with the connection and the second organization may associate ingredient D with the connection. The table shown in FIG. 5 may be populated with relevant connections, ingredients, and recipe information.

[0077] 4, mapping the network of nodes onto the data table may include storing entity specific (e.g., organization profile) information for the plurality of nodes 402 in organizations 502 and storing node connection information for the plurality of nodes 402 in connections 504. As described in more detail below, processing the network to generate vectors for the plurality of nodes 402 may include storing the vectors represented by recipe 506, ingredients 508, recipe_ingredients 510, recipe_consumers 512, and / or ingredient_suppliers 514. , can be managed based on the association between owned recipes and owned ingredients.

[0078] In some embodiments, updates or changes may be requested by a user (e.g., associated with one of the nodes / entities of the network). For example, an authenticated user may request a change to the network, such as a change to the flow of goods or products (e.g., a new or updated supplier / customer relationship), a new flow of goods or products, a change to owned recipes or ingredients, a new recipe or ingredient, or any other suitable change. Changes to the network may include the creation of a new node / entity based on a newly registered organization. The new node / entity may create connections with existing entities / nodes based on existing or new flows of goods or products.

[0079] The new connections 408 shown in FIG. 4 may be the result of changes to the graph 400. For example, multiple nodes 402 connected by new connections 408 may have an engagement to trade goods or services. Based on the updates to the graph 400, new paths and new potential paths are generated. As detailed herein, the processing requirements for traversing a graph, such as a social graph, with a high frequency of changes may be computationally challenging. An embodiment implements drip-feed delta processing to provide an efficient technique for traversing the graph 400 even in the presence of frequent changes.

[0080] FIG. 6 illustrates a flow diagram for delta processing for a network of nodes, according to an exemplary embodiment. A delta 602 may be requested as an update or change to network data 606 (e.g., stored in a relational data table). The delta 602 may be stored in a queue 604, such as a First in First Out (FIFO) queue or any other suitable queue. Each change or update processed may be considered a drip in a drip-feed delta processing flow. When an update or change is made on the network data 606, one or more paths or potential paths between entities of the network may be altered. For example, one of the deltas 602 may result in a change that creates a connection similar to the new connection 408 and / or creates a new (or new potential) flow of products or goods (e.g., based on changes to an owned ingredient, recipe, or product). Upon completing the update to the network data 606, the next drip may be performed (e.g., the network data 606 may be updated or altered according to the delta 602 at the head of the queue 604).

[0081] In some embodiments, network data 606 may represent a pre-computed version of the underlying network data (e.g., stored in the relational tables shown in FIG. 5). For example, network data 606 may be pre-computed data useful for efficient retrieval of network information (e.g., supply chain information) such as paths between nodes / entities. A user (e.g., an authenticated user with appropriate security) may immediately update / change the underlying network data, e.g., by logging into and interacting with a client application, and these updates / changes may be reflected in the underlying network data without the use of queues. However, delta 602 may represent updates / changes that affect network data 606 (e.g., the pre-computed version of the underlying network data). An embodiment implements a drip-feed delta technique when updating network data 606 to maintain this pre-computed version of the underlying network data useful for efficient retrieval of network information.

[0082] In some embodiments, network data 606 is stored in a set of relational data tables that are separate from the underlying network data. Network data 606 can be thought of as a copy of the underlying network data in a pre-computed form. To maintain this pre-computed form (and the benefits of efficient network data retrieval), updates are managed by the disclosed drip-feed delta technique. In other words, it is updates / changes to a separate set of relational data tables (e.g., delta 602) that are queued (e.g., in queue 604) and executed as drip deltas. Network data 606 eventually coincides with the underlying network data (after execution of drip deltas), providing a structure that enables high-performance querying of the network.

[0083] In some embodiments, the processing of deltas 602 is done under best-effort conditions based on available computational resources. Processing delays may result from the discrepancy between the rate at which the server can generate deltas 602 (from user activity) and the rate at which the pre-computation engine can process / remove them from the queue 604. In some embodiments, delta processing may be delayed and / or may be done at predetermined intervals (e.g., delays may be built into the processing).

[0084] In some embodiments, updates / changes to the underlying network data (e.g., changes to the relational data tables of FIG. 5) may be tracked to determine changes that affect the separate data tables that store network data 606. For example, the following scenarios represent changes (e.g., queued changes) that affect network data 606: 1) Two organizations create a new business relationship or end an existing business relationship; 2) two organizations end an existing business relationship; 3) recipes or ingredients maintained by customers or suppliers are updated to associate the new organization as a customer (of products / recipes) or supplier (of ingredients); 4) Recipes or ingredients maintained by customers or suppliers are updated so that they remove the organization as a supplier of ingredients or customer of the product / recipe.

[0085] In some embodiments, updates / changes to the underlying network data may be tracked to identify one or more of these above-mentioned scenarios. For example, with reference to the relationship table structure of FIG. 5, the following updates / changes may be identified as affecting network data 606: Consumers added to / removed from recipes (insert, delete on recipe_consumers 512) Ingredients added to / removed from recipe (insertion, deletion on table Recipe_Ingredients 510) Suppliers added to / removed from ingredients (insertion, deletion in table Ingredient_Suppliers 514)

[0086] Note that in each of these cases, the changes may be implemented by a user (e.g., an authenticated user with authorization) using a client application. Embodiments of the disclosed techniques generate deltas 602 corresponding to these changes that are used to update network data 606 to maintain a pre-computed version of the underlying network data.

[0087] In some embodiments, database functions (e.g., Oracle® RDBMS triggers) may be used to process deltas 602. An exemplary technique for queuing includes Oracle® AQ ("AQ": Advanced Queuing). Deltas 602 from queue 604 may be processed and a data table storing network data 606 (e.g., containing a transitive closure for the graph) may be updated incrementally. In some embodiments, multiple queue consumers may be implemented at different organizations, and these may be shared by different organizations. An exemplary schema for a data table storing network data 606 is as follows: PRECOMPUTE_RECIPE_CONSUMER_SUPPLIER - Stores a precomputed copy of a recipe for a consuming organization relationship (recipe ID, consuming organization ID and supplying (owning) organization ID). Precalculated_Recipe_Ingredient - Stores a precalculated copy of the ingredient for the recipe relationship (recipe ID and ingredient ID). Precalculated_Ingredient_Consumer_Supplier--Stores precalculated copy of ingredient for Supplying Organization relationship (Ingredient ID, Consuming (Owning) Organization ID and Supplying Organization ID). precomputed_raw_connections - Stores precomputed versions of raw materials for raw connection that are possible and can therefore be used for traversal through the network. This is used to aid in the incremental evaluation of the transitive closure. PRECOMPUTE_ORGANIZATION_TRANSITIVE CLOSURE_RECURSIVE--One of the tables used by applications to store a precomputed version of an organization's transitive closure and query the network. In some embodiments, the table design is simple, consisting of an ID (of its recursive transitive closure entry), a consuming organization ID, and a supplying organization ID. Precomputed_Organization_Transitive Closure_Paths--stores all precomputed versions of paths that can be taken from a consuming organization ID to a supplying organization ID in the precomputed_organization_transitive closure_recursive. PRECOMPUTE_ORGANIZATION_TRANSITIVE CLOSURE_Raw_CONNECTION_PATH_HEADER - This table holds a header record for a raw material path. This record contains the organization's transitive closure path ID from the PRECOMPUTE_ORGANIZATION_TRANSITIVE CLOSURE_PATHS that this raw material path enables. This is used to aid in the incremental evaluation of the transitive closure. Precalculate_Organization_Transitive Closure_Material_Connection_Path_Details - This table holds detailed records for material paths from the Precalculate_Organization_Transitive Closure_Material_Connection_Path_Header. It is used to aid in the incremental evaluation of the transitive closure.

[0088] Embodiments include generating updates / changes (e.g., deltas 602) to data tables that store network data 606 (e.g., the schema described above) that correspond to changes identified and tracked as affecting network data 606. For example, a tracked change may be identified as an update to a business relationship between two entities / nodes. One or more deltas 602 may be generated to update the data tables that store network data 606. For example, the tracked changes may correspond to multiple deltas 602 that update / modify multiple tables that store network data 606 based on the implemented schema.

[0089] In some embodiments, performing a drip (e.g., delta) includes determining the transitive closure of the network. With reference to FIG. 4, the transitive closure of the graph 400 may be maintained for a given node based on a subset of the nodes 402 that are part of a path or potential path to the given node. Potential connections or flows of goods or products may be identified based on ingredients, recipes, related entities / nodes, and associated information stored and updated in a data schema (e.g., data schema disclosed above) maintained for the network data 606. In general, for a given node, the transitive closure of the graph 400 represents a subset of the nodes 402 that may be included on a (e.g., existing or potential) path to the given node. The transitive closure for the graph 400 may be determined in any suitable manner (e.g., a breadth-first or depth-first search of the graph, the Floyd-Warshall algorithm, etc.).

[0090] When determining the transitive closure, a set of rules or data may be used that enumerate paths from a node to other nodes. In various embodiments, established business relationships between nodes / entities may be used as a technique for enumerating paths. The following is an exemplary algorithm for determining the transitive closure of graph 400: For node X; For each recipe in X, For each ingredient in the recipe, For each supplier of raw materials: Add the supplier to the list of potential supplier nodes. For each node in the "potential supplier nodes" list, Check if the node has at least one recipe with node X marked as a customer. If the node does not have at least one such recipe, remove the node from the "potential supplier nodes" list. / / A "potential supplier node" is a next level node in the supply chain to node X. The algorithm recurses over each node in the list, yielding the next level of suppliers for the node. For each new recursion, the node that is the target of the current iteration becomes the new "X".

[0091] The results of the determined transitive closure may be stored as network data 606 (e.g., in a data table similar to the exemplary schema). With reference to Figure 6, delta 602 may be generated based on one or more changes to the underlying network data (e.g., stored in a data table of Figure 5) performed by a user such that each data table that stores network data 606 that is affected by the change to the underlying network data is updated. In other words, given a network data change to a piece of information A, delta 602 may be generated to update any data tables for network data 606 that store information A or that store information that is dependent on information A.

[0092] In some embodiments, maintaining the transitive closure of graph 400 involves modifying a pre-computed version of the network data (e.g., network data 606) rather than recalculating the entire transitive closure. If a full rebuild is required, for example, based on a database failure or some other need, a rebuild of the transitive closure can be done based on the connection, recipe, and ingredient records.

[0093] In some embodiments, determining the transitive closure for graph 400 provides a direct access vector for each of multiple nodes 402. For example, the transitive closure for graph 400 can provide a list of all nodes that can be reached from a given node: Given a node "X", the closure for "X" is a list of objects where each object can be represented as follows: 1) The ID of a node ("Y") that can be reached from "X". 2) A set of alternative paths that describes all possible ways to get from "X" to "Y" in the graph. Each alternative path may include a list of node IDs that will be traversed to get from "X" to "Y".

[0094] The direct access vector for a given node may be selected in a relationship data query to return a subset of nodes that are part of a path to the given node. In other words, a request to traverse the graph 400 and return a path to a given node may use the direct access vector for the given node and the relationship query to efficiently retrieve the requested network data from a relationship data table (e.g., a data schema for network data 606). The embodiments provide computationally efficient techniques for traversing the graph 400 to provide network software services such as path identification and corresponding data retrieval.

[0095] In some embodiments, software services such as stateless microservices can be leveraged to access, update, modify, delete, or retrieve data for a network of nodes. While delta processing for updates or modifications to network data allows for efficient access of this data, some organizations may store sensitive or confidential information in the system. Therefore, security policies and secure filtering of network data can be provided to further improve management of network data.

[0096] 7 is a functional diagram for secure management of data processing for a network of nodes, according to an example embodiment. For example, diagram 700 may represent software functions for achieving secure data processing for a network of nodes as disclosed herein.

[0097] Diagram 700 includes services 702, a data platform 704, a security platform 706, and data storage 708. Data platform 704 may include application programming interfaces ("APIs") 710, XML definitions 712, and logical-to-physical mappings 714. Security platform may include data editing 716, relationship filtering 718, trusted store 720, and XML configuration 722. In some embodiments, services 702, data platform 704, security platform 706, and data storage 708 may be similar to services 310, data platform 312, security platform 314, and data storage 316 of FIG.

[0098] In some embodiments, services 702 may include multiple microservices that provide for user interaction with the network of nodes. For example, a user (operating a client device) who is subscribed to a registered organization (e.g., an entity of the network) can call various microservices using multiple exposed APIs to interface with the network systems and access network data.

[0099] In some embodiments, the services 702 communicate with the data platform 704 using an API 710 to access, update, modify, or delete network data stored in the data storage 708. The XML definition can define the data that can be retrieved from the data storage 708. Additionally, a logical-to-physical mapping 714 can be used to map logical data requests or commands to physical level requests or commands (e.g., relational data queries).

[0100] In some embodiments, physical level requests or commands (e.g., structured query language ("SQL") commands or queries) are communicated to security platform 706 for filtering or expansion according to stored security protocols before executing these requests or commands on data storage 708. Trusted store 720 is an immutable source of security policies for the network that stores access permissions for registered users and organizations.

[0101] For example, access to data store 708 may be protected according to access permissions stored in trusted store 720. In some embodiments, trusted store 720 may store an organization key used to write first organization profile data. In this example, users of the first organization may write profile data to their own organization, but are prevented from writing profile data to any other organizations, even if such writing is requested by one or more of services 702 or by other code in the network system.

[0102] In some embodiments, queries or instructions (e.g., SQL) communicated from data platform 704 may be filtered or expanded by relationship filter 718 according to security policies stored in trusted store 720. Additionally, any data retrieved by a filtered or expanded query may be edited by data editing 716 according to security policies stored in trusted store 720. In some embodiments, security platform 706 may be configured with XML configuration 722, which may include multiple XML files that define security protocols (e.g., access permissions, query filtering, and data editing).

[0103] An embodiment includes multiple stateless microservices available for interfacing with a network system. In some embodiments, microservices are independently deployable services. In some embodiments, the term microservices refers to a software architecture design pattern in which complex applications consist of small independent processes that communicate with each other using language-agnostic APIs. In some embodiments, microservices are small services that are highly decoupled, each of which may focus on performing a small task. In some embodiments, the microservices architectural style is an approach to developing a single application as a set of small services, each of which runs in its own process and communicates with lightweight mechanisms (e.g., HTTP resource APIs). In some embodiments, microservices are easier to replace compared to a monolithic service that performs all or much of the same functionality. Moreover, each of the microservices may be updated without adversely affecting the other microservices. In contrast, updates to one part of a monolithic service may undesirably or unintentionally negatively impact other parts of the monolithic service. In some embodiments, microservices may be beneficially organized around their capabilities. In one embodiment, the startup time for each of a collection of microservices is much shorter than the startup time for a single application that collectively services all of those microservices.

[0104] In one embodiment, microservices architecture refers to a specialization (i.e., separation of tasks within a system) and realization approach to service-oriented architecture ("SOA") for building flexible, independently deployable software systems. Services in a microservices architecture are processes that communicate with each other across a network to fulfill a goal. In one embodiment, these services use technology-agnostic protocols. In one embodiment, the services have small granularity and use lightweight protocols. In one embodiment, the services are independently deployable. By distributing the functionality of a system across different small services, the system is made more consistent and less coupled. This makes it easier to change the system and to add functionality and quality to the system at any time. It also allows the architecture of individual services to emerge through constant refactoring, thus reducing the need for extensive upfront design and allowing software to be released early and continuously.

[0105] In one embodiment, in a microservices architecture, an application is developed as a collection of services, each service running its own process and using a lightweight protocol (e.g., a specific API for each microservice) to communicate. In a microservices architecture, the decomposition of software into individual services / functions can be done at different levels of granularity depending on the services provided. A service can be a runtime component / process. Each microservice can be a self-contained module that can interact with other modules / microservices. Each microservice can have an unspecified universal port that can be contacted by other microservices. In one embodiment, a microservice's unspecified universal port is a standard communication channel that the microservice exposes by convention (e.g., as a conventional Hypertext Transfer Protocol ("HTTP") port) and allows any other module / microservice within the same service to interact with it. In one embodiment, microservices are independent of each other, atomic, and stateless. A microservice or any other self-contained functional module can be generally referred to as a "service."

[0106] For example, one of the stateless microservices may be an identity management service used to authenticate a user's identity, such as an IDCS microservice. For example, a user associated with an organization may provide their organization credentials, and the IDCS microservice may be configured to perform authentication with the user's organization's identity management system to ensure that the user's identity is properly authenticated by the associated system. The following example represents a subset of the APIs for an IDCS microservice: User GetCurrentUser Gets the current user, identified by the currently logged in user. User GetUser(String emailAddress) Get the user identified by their email address by querying IDCS for the Username attribute. String CreateUser(User toCreate) Creates new users and adds them to groups. Group display names can be configured in the application context parameters (web.xml). The IDCS groups to which the user is added can be searched before the user is created. The search can call an API to search for groups with display names matching the parameters that are set. Once found, it can extract the group Id (not visible through the UI) and use that group Id to make an update (PATCH) request to the IDCS server to add the newly created user. The newly generated user Id (GUID) is returned after the operation is successful.

[0107] In some embodiments, various microservices may rely on each other's APIs to perform functions. For example, the IDCS microservice may rely on functionality provided by one or more other microservices to achieve the functionality described above for the example API. Additionally, the IDCS microservice may request functionality from an organization's identity management system to fully accomplish user authentication. For example, an organization may implement a cloud-based user authentication system, such as that described in U.S. Patent No. 9,838,376.

[0108] In another example, one or more microservices are used to create, read, update, or delete ("CRUD") network data from data storage 708. For example, various microservices can expose custom or CRUD interfaces that provide access to the "business functions" that the microservices represent. In some examples, a microservice can represent a business entity (e.g., a company profile, a list of invitations, recipes, etc.). CRUD verbs can allow the corresponding stream of an entity to be read or manipulated. As described in more detail below, such services can further rely on the capabilities of security platform 706 to ensure compliance with the system's security policies. The following example represents a subset of an API for one or more CRUD microservices:

number

[0109] In another example, the organization microservice may be used to manage information for organizations registered with the network of nodes. For example, each organization may have a profile that includes multiple attributes, as described above. The organization microservice may invoke one or more functions of the CRUD microservice to access, create, or update organization information stored in data storage 708. For example, the following functions may be provided by the organization microservice: Create -Standard creation based on CRUD microservices - Rely on data constraints in the data source to enforce required fields Read -Standard read based CRUD microservices Update -Standard updates based on CRUD microservices - Rely on data constraints in the data source to enforce required fields Update Create -Standard update and create based on CRUD microservices - Rely on data constraints in the data source to enforce required fields

[0110] The Organization microservice can also be used by users to find organization-specific information and retrieve an organization's products. The following example represents a subset of the API for the Organization microservice:

number

[0111] In some embodiments, the IDynamicDataRecordSet (IDRS) is a generic data structure that allows a variable stream of data to be represented. An IDRS may contain several parts: 1) A list of records that the data stream represents, e.g., one per entity. 2) Each entity record may have a set of attribute pairs: an attribute ID and an attribute value. 3) Each entity record may itself contain a list of entity records. Examples including such features may allow for hierarchical representations. 4) In parallel with the above data, IDRS may contain metadata. The metadata may have an entry for each attribute available in the entity record. This metadata describes the characteristics of the data. Examples are: a. Physical data type in the database, e.g. text b. Business type - e.g. password c. Range of possible values d. Required flag e. Enabling Rules f. Default value g.Other similar items

[0112] Embodiments utilizing IDRS can leverage the benefits of data structures, at least because data structures can represent values, records, lists, hierarchies, and other concepts in a standard way. These representations can be self-describing, for example, because of the metadata they contain. Network data embodiments can be represented as IDRS structures. Such embodiments allow a common processing unit or UI component to accept an unusual amount of data, at least because the IDRS structure provides an indication as to how to navigate and understand it.

[0113] In another example, the User Profile microservice may be used to manage user profiles for users of a network of nodes. For example, each user may have a profile that includes user-specific information, such as organizational affiliation. The User Profile microservice may invoke one or more functions of the CRUD microservice to access, create, or update user profile information stored in data storage 708. For example, the following represents a subset of functions that may be provided by the User Profile microservice: Create -Standard creation based on CRUD microservices Read -Standard read based CRUD microservices Update -Standard updates based on CRUD microservices Create Update -Standard update and create based on CRUD microservices

[0114] In another example, the ingredients microservice can be used to interface with ingredient information stored in data storage 708. A subset of functions for the ingredients microservice is as follows: Definition: Metadata Definition ·Raw materials Provided by RdbmsStandardAttributes ·Raw materials _CRUD Provided by RdbmsStandardAttributes Dynamic Data Definition ·Raw materials Read Caption, ParentProductId, and OwnerOrgId ·Raw materials_CRUD Provided by RdbmsStandardAttributes function: Standard CRUD operations are achieved as follows: Read It is implemented as part of CrudBase using the Raw Material Data Stream. Delete Overwritten with raw_CRUD data stream. CreateItemsEx(Long denerOrgId, Long parentProductId, IDynamicDataRecordSet items) throws ORSCN_ServiceException. Iterate through the items list and set the OwnerOrgId and parentProductId, Invoke repository create using the raw_CRUD data stream. UpdateCreateEx(Long ownerOrgId, Long parentProductId, IDynamicDataRecord item) throws ORSCN_ServiceException. Set OwnerOrgId and parentProductId, Update the repository using the raw_CRUD data stream and call updateCreate. ReadIngredient(Long ingredientId) throws ORSCN_ServiceException. Call the static readIngredient on the ingredient entity, If ingredientId is null, null is returned. Call repository read using the ingredients_CRUD data stream and filter on ingredientId. o If an ingredient is returned, extend the supplier information by calling a read on the repository using the IngredientSuppliersCaptions data stream and replacing the supplierIds attribute. Update If this is not the case, an exception is thrown. Create If this is not the case, an exception is thrown. Create / Update If this is not the case, an exception is thrown.

[0115] In another example, a similar recipe microservice is used to interface with recipe information stored in data storage 708. A subset of functionality for the recipe microservice is as follows: Definition: Metadata Definition Recipes Provided by RdbmsStandardAttributes · Recipe_CRUD Provided by RdbmsStandardAttributes Dynamic Data Definition Recipes Read Caption, ParentProductId, and OwnerOrgId · Recipe_CRUD Provided by RdbmsStandardAttributes function: Standard CRUD operations are achieved as follows: Read Implemented as part of CrudBase using recipe data streams. Delete Overridden using the recipe_CRUD data stream. CreateItemsEx(Long ownerOrgId, Long parentProductId, IDynamicDataRecordSet items) throws ORSCN_ServiceException. Iterate through the items list and set the OwnerOrgId and parentProductId, Call repository create using the recipe_CRUD data stream. UpdateCreateEx(Long ownerOrgId, Long parentProductId, ID dynamicDataRecord item) throws ORSCN_ServiceException. Set OwnerOrgId and parentProductId, Create a repository using the recipe_CRUD data stream and call updateCreate. ReadRecipe(Long recipeId) throws ORSCN_ServiceException. Call the static readRecipe on the recipe entity, If recipeId is null, null is returned. Call a repository read using the recipe_CRUD data stream and filter on recipeId. If a recipe is returned, extend the customer information by calling a read on the repository with the RecipeConsumersCaptions data stream and replacing the consumerIds attribute. If a recipe is returned, extend the ingredient information by calling a read on the repository using the RecipeIngredientsCaptions data stream and replacing the ingredientIds attribute. Update If this is not the case, an exception is thrown. Create If this is not the case, an exception is thrown. Create / Update If this is not the case, an exception is thrown.

[0116] As mentioned above, the exemplary microservices can be stateless in embodiments, thus greatly simplifying their interaction with one another. In some embodiments, a session state microservice is provided to enable access to Distributed Object Model ("DOM") objects that are persisted on an application session. In one example, the simplified API for the session state microservice is the following interface: sessionDOM GetSessionDOM(), which can return an object that provides the session DOM.

[0117] In some embodiments, a DOM object may be a data structure that collects a diverse set of data that represents the state of a logged-in user's session on the network. The data may be frequently accessed data (e.g., security rules) that is accumulated on demand, or a set of discrete items about the logged-in user (e.g., current user, language preference, user origin, current network visibility report, etc.). In accordance with a microservices architecture, an embodiment includes a single service to read and update data in the DOM. This service may be used by network application logic when data is requested from the DOM. In some embodiments, the data in the DOM may be physically anchored to the session state (e.g., maintained by an application server).

[0118] As described herein, drip-feed delta processing for a network maintains a network configuration for a given organization / entity / node (e.g., direct access vector for a given node), which can be easily used to query data storage 708 to traverse a graph representing the network of nodes (e.g., identify existing or potential paths / supply chains that include a given node). An exemplary network traversal microservice used to traverse a network can be provided to return paths for an organization (e.g., an entity or node in the network). A subset of functionality for an exemplary network traversal microservice is as follows: Data Layout A simple 4 column table with one row per connection (connectionId, destination, source, type). Reverse connections are not stored. Type c=consumer, s=supplier, given X and Y, X c Y (X consumes Y), and Y s X (Y supplies X) are equivalent. Object network IDDRS <organisations>organisations List <connection>connections connection Long formNodeId Long toNodeId Enum connectionType API public Network readNetwork(Int startOrganisationId, int depth)

[0119] In some embodiments, the network traversal microservice can return network paths (e.g., supply chains) for a requesting user's organizations. For example, the returned data can represent paths such as pairs of organizations (e.g., identified by IDs) along with the nature of the relationships (e.g., trading partner, supplier, customer, etc.) that connect these organizations. In some embodiments, this service can be used to view and search an organization's supply chain.

[0120] The organizations representing the supply chain (returned by this service) may be defined by the connections and the goods or products traded between them. In some embodiments, to deliver the list of connected nodes, the microservice uses information about the connections accepted and the products traded, but in some embodiments, this information is used but not returned. For example, in some embodiments, the set of organizations representing the supply chain is returned as a result, but the additional information described above that was used to determine the result set is not returned.

[0121] As will be further detailed with reference to Figures 8-14, visualizations can be displayed to users of the network system, which in some examples may include visualizations of data protected with the security policies of the network system, such as visualization of paths of nodes / entities representing a supply chain. An exemplary visualization microservice can be provided and used to create, edit, or update visualizations for the network system. A subset of functionality for the visualization microservice is as follows: function: Create ○Ensure that all required characteristics are provided. Create a new visualization. Read ○ Read the current visualization for the current organization. Retrieving a visualization in this way returns everything needed to create the visualization minus the actual data. This can be used to retrieve and edit the visualization specification without having to read all the network data. ·Read Visualisation Data This operation reads the visualization that contains the actual network data needed for the UI to display. ·Update Update visualizations with data provided. Delete Remove the visibility from the DOM. A visualization can be defined as follows: TIFF0007653489000003.tif137117 Creation Creating a visualization requires that required attributes be provided, otherwise an exception is thrown. Once created, a visualization can be edited. The visualization data is looked up through the connection service before it is displayed, taking into account options and filters. Editing Any attribute can be edited, except for the ID. Changing a visibility attribute may require the data to be re-read for the changes (e.g. changing options or filters) to take effect.

[0122] Referring again to Figure 7, the services 702, data platform 704, security platform 706, and data storage 708 may be configured to enable information sharing between entities / nodes / organizations in the network. The network system is based on the fluid sharing of data rather than silos of private data, even if some of this data is confidential or sensitive. Thus, network data may be shared between nodes / entities / organizations according to sharing rules based on the relationship between the node / entity / organization requesting access to the data and the node / entity / organization that owns the requested data record.

[0123] An example sharing rule for a given node / entity / organization is as follows: a data record (e.g., a row in a table) owned by a given entity allows access to any entity with which an existing flow of goods or products exists with the given entity (e.g., the entity is a trading partner or is on a supply chain path) and does not allow access to entities that do not have an existing flow of such goods or products. In other words, a given entity may allow trading partners to access certain data that non-trading partners cannot access. Different network sharing rules may be defined for different groups of field data (e.g., columns) within the same record (e.g., row). In some embodiments, sharing rules may be defined for individual users for each separate functional area of ​​the network system.

[0124] As described in more detail herein, the entities of the node network may be organizations, and the data storage 708 may store profile information for the organizations. For example, a profile may be stored for a registered organization and may include one or more of the name, address or location (e.g., latitude, longitude, home country, and any other suitable location information), brands associated with the organization, a home page uniform resource locator ("URL"), social media accounts for the organization, combinations thereof, and other suitable information.

[0125] In some embodiments, the network of nodes may represent a network of suppliers, customers, and / or intermediaries. In such an example, the organizational profile may also include one or more of products sold, products purchased, certificates from third party organizations, expired certificates from third party organizations, direct suppliers (e.g., from among other entities in the network), direct customers (e.g., from among other entities in the network), instructions (e.g., recipes) for the goods or products, parts of the goods or products (e.g., ingredients), combinations thereof, and any other suitable information for the goods or buyers or sellers of the goods.

[0126] In embodiments including social aspects (e.g., posts, messages, etc.) for network nodes, the system can manage social data for the entities, such as data for messages, posts, discussion groups, and other social interactions. In addition, the entities further include network data related to their orientation in the network, such as connections between the entities / nodes, paths to the entities / nodes (e.g., direct access vectors), and other suitable information related to the orientation of the entities / nodes in the network.

[0127] In some embodiments, an entity can define specific sharing rules for each piece of data owned by the entity (e.g., different data items related to an organization profile, social network data, network-oriented data, etc.). For example, a portion of an organization's profile can have public sharing rules (e.g., available to anyone), while a certificate or expired certificate can have sharing rules for direct business relationships (e.g., available only to business partners). Exemplary sharing rules are as follows: Public – the data is available to anyone on the Internet. · Network - Data is available to any registered user / organization. Anyone with a user account that can log into the system. Direct Business Connection – Data is available to users in organizations with which the source organization has a direct business relationship. They either supply, consume, or both supply and consume, and consume directly with the source organization. Customer Connectivity – Data is available to users in organizations that are customers of the source organization. Supplier Connection - Data is available to users in organizations that are suppliers to the source organization. Potential Connections - The data is available to users within an organization with whom the source organization has a potential connection (e.g., potential flow of goods or products) based on a match between ingredients and recipes owned by the organization (as further described herein). Specific Organizations - Data is available to anyone from within a specific list of organizations. Organizations can be selected from all organizations on the network. · Private - The data is only available to users within the organization that owns the data.

[0128] In some embodiments, the security platform 706 makes access permission decisions based on these sharing rules (e.g., stored as access permissions) for each source entity and the relationship between the source entity and the user requesting the source entity's data. The relationship between entities / organizations may be stored as network data. In some examples, the relationship may be defined by which invitations have been sent and accepted to indicate a business relationship. For example, customer "X" may request that organization "Y" connect to them as a supplier. If this invitation is accepted, supplier "Y" has visibility to data that owner "X" has marked as "only visible to supplier."

[0129] In some embodiments, upon resolving the data sharing rules and determining whether there is user permission to retrieve data owned by the source entity, relationship filtering 718 augments the data query (e.g., an SQL query) submitted on behalf of the authenticated user (via services 702 and data platform 704) with a "key" to retrieve the data from data storage 708. The augmented query may then be executed in data storage 708 to retrieve the requested data. In some embodiments where data store 718 determines that the user is not authorized to access the requested data, the associated "key" for that data is not added to the query and therefore, no data will be returned when the query is made in data store 718.

[0130] In some embodiments, the security platform 706 has access to a "current login organization ID." This may be immutably stored in the trusted store 720 by the login process based on the organization associated with the authenticated user. Tables in the data storage 708 that contain sensitive information (e.g., information protected by one of the security policies / sharing rules described above) may key their records by the organization ID of the entity / organization that is considered to "own" the records. As disclosed above, each entity / organization may grant access to individual organizations, or to "classes of organizations" associated with them, in a specific manner based on specific sharing rules / access permissions (e.g., customer, supplier, etc.).

[0131] In some embodiments, tables that store network data in data storage 708 have an associated "security descriptor" or XML representation of rules that indicate how an organization requesting access to the data must be related to the owner of the row of data (if the row is accessible). For example, the XML can define sharing rules / access permissions for records in associated data tables. Security platform 706 uses the XML relationship rules and the "current login organization ID" to determine the set of other organizations from which an organization's data may be accessed.

[0132] In some embodiments, the relational filtering 718 modifies the SQL access statement such that an additional WHERE clause qualifier is added to any filtering already specified in the SQL (e.g., by the data platform 704). This additional qualifier can enumerate a set of valid organization IDs (e.g., according to the current login organization ID and an XML security descriptor), one of which must be present in the organization key of a row of data for the record to be matched and included within the scope of the query.

[0133] In some embodiments, data editing is performed by Data Editing 716 after the SQL result is received but before it is returned to the calling application. For example, a WHERE key modification process may have restricted the rows accessed by the SQL, but various fields of these rows may be read without considering security protocols. In some instances, a data owner may allow access to a record, but not all fields within the record. Data Editing 716 may be used to address such scenarios and edit column level data.

[0134] In some embodiments, each returned record is post-processed by data editing 716 to remove any field data that is not approved by the data owner as accessible to the current organization. In some embodiments, a row set (e.g., a returned data set) will be returned only after key filtering and editing.

[0135] As an example, a requesting organization / application / microservice may attempt to read a table with an unrestricted "*" SQL where clause. The security platform 706 may then identify the requester using the "current logged-in organization ID" from the trusted store 720. The security platform 706 may then compute the set of other organizations that have granted access to this organization. Relationship filtering 718 may add an additional WHERE qualifier to the SQL to filter out data owned by organizations that do not allow this access. Hence, retrieval from such an unrestricted SQL statement is much safer due to the added WHERE qualifier. This will return the complete recordset.

[0136] In some embodiments, Data Editing 716 can then analyze the data retrieved to remove any fields that the record's owning organization has not permitted the requester to view. For example, for each record, security protocols (e.g., access permissions / data sharing rules / security descriptor files) can be accessed to determine the column level access the requesting organization has in relation to the record's owner. If it is determined that the requesting organization does not have column level access to the data, that data can be removed from the result set. The relationship filtered and edited data can then be returned to the requesting organization. In some embodiments, this can be an empty set of records.

[0137] The following represents an example XML that defines the permissions used by the security platform 706 to perform the security functions described above:

number

[0138] In some embodiments, user-based functional security rules control "who" can do "what" in the source organization. They can also control who has access to what on the underlying source organization data. Security templates are used to define what functional security a user has at the time the template is created. An administrator (a user with sufficient privileges) can control by functional security settings whether it is allowed for a given user in that organization or whether it is revoked from that user. The available security templates, and their associated privileges, are shown in Tables 1 and 2 below. For example, three templates can be considered: Admin - a user who can fully manage the organization, including managing users and connections and all data belonging to those organizations; User Editor - a user who can contribute by making social posts, managing company profiles, etc., but cannot perform security related operations such as managing users and connections, etc.; User Reader - a user who can only view and analyze information. They cannot make any changes. Generally, this user is a read-only user. [Table 1] [Table 2]

[0139] In some embodiments, data retrieved from the social network may be used for various functional purposes. For example, one or more visualizations may be generated that show an organization's orientation in a pathway (e.g., a supply chain). FIG. 8 illustrates an example graphical user interface for configuring a view of a network of nodes, according to an example embodiment. For example, a user within an organization may operate a client device configured to display a dashboard 800 for displaying a visualization of a supply chain. The network data retrieved to generate the visualization may leverage one or more of the disclosed features. For example, the visualization may be generated based on vectors (e.g., direct access vectors) retrieved for a given node from a pre-computed version of the stored network data. The retrieved network data may be secured using relationship filtering and data editing features that manage storage security policies in relation to a given node.

[0140] In some embodiments, dashboard 800 may include user interface elements (e.g., widgets) including filter options 802, configuration options 804, enablement 806, depth 808, visualization options 810, and attributes 812. For example, filter options 802 may be used to determine the type of filter for which organizational data is displayed by the visualization. The options shown include a country filter, an organization name filter, a products purchased filter, a products sold filter, an expired certificate filter, a material filter (e.g., ingredients), and a product lineup filter.

[0141] 8 shows an example where "Expired Certificates" is the filter that is selected. Configuration options 804 can allow configuration of the filter that is selected. In the embodiment shown, the filter is configured to display entities in the supply chain that have more than "0" expired certificates. Enable 806 allows the user to enable or disable the filter.

[0142] Depth 808 allows a user to select a depth in the supply chain (e.g., to display nodes / entities / organizations with a distance equal to or less than the selected depth, where distance is the number of jumps or hops away from the source node / entity / organization in the network). Visualization options 810 allow a user to select a visualization type, such as a pie chart, bar chart, network graph, table, or world map. FIG. 9 illustrates a pie chart visualization of network data according to an exemplary embodiment. FIG. 10 illustrates a table visualization of network data according to an exemplary embodiment. FIG. 11 illustrates a network graph visualization of network data according to an exemplary embodiment. FIGS. 12-14 illustrate a world view visualization of supply chain data according to an exemplary embodiment.

[0143] Data attributes 812 allow the user to select data attributes used by some visualizations. For example, pie chart 900 in Figure 9 shows a pie chart segmented by country. If the user wants a broader view of the data for a supply chain visualization, data table 1000 in Figure 10 provides a larger cross-section of the network data. Network graph 1100 in Figure 11 represents a visualization of network nodes and connections between these network nodes that display the various links involved in the supply chain.

[0144] The world view visualization 1200 of Figure 12 depicts supply chain connections overlaid on a world map. In this example, the user is shown various regional risks in the supply chain. The user can further request more granular information about the links in the supply chain by selecting (e.g., clicking or tapping) one of the points in the supply chain. The world view visualization 1300 of Figure 13 includes a widget 1302, an overview 1304, and an indicator 1306 that are displayed upon selection of a link in the supply chain.

[0145] Widget 1302 may be used to select organization information for display. Overview 1304 provides an overview of the selected organization (e.g., the filter used to generate the visualization depicted), including the number of expired certificates. Indicator 1306 may indicate the conditions for the particular filter used to generate the visualization. In the embodiment shown, the selected organization has expired certificates, so indicator 1306 shows a red exclamation point. In some examples, if the organization does not have expired certificates, a green check may be displayed. Visualization 1400 of FIG. 4 similarly includes widget 1402 and overview 1404, which display an overview of different organizations in the supply chain.

[0146] The various disclosed embodiments have many advantages over traditional data management and security applications. For example, embodiments including drip-feed delta processing and pre-computed versions of network data can substantially reduce the computational complexity associated with traversing large graphs of nodes. At a minimum, the direct access vectors generated provide an efficient solution to querying relational databases to quickly and accurately retrieve network data. Such efficiency and high accessibility enables the provision of robust software services from network systems, such as the visualizations disclosed herein. The more cumbersome, less efficient, and computationally challenging approaches taken by traditional data management systems fail to achieve these benefits.

[0147] For example, some data schema embodiments are designed to represent and answer questions over connection graph networks. However, many of these are optimized for frequent reads and occasional updates. In various embodiments, the network may undergo frequent updates as new relationship connections are added / updated across participating organizations from time to time. The disclosed drip-feed delta processing provides technical advantages in such environments.

[0148] Another alternative could be a simple on-demand recursion of relational network connection tables. Traditional approaches leveraging such simple systems can handle frequent updates, but traversing the graph represented by the stored data can be computationally difficult. Drip-feed delta processing solutions, and pre-computed versions of the network data, can provide efficient traversal even in the presence of frequent updates, which yields a performance advantage over these traditional techniques.

[0149] Additionally, embodiments including the trusted store and data security policies ensure that the network of nodes can store and share private, sensitive, or confidential data between different organizations in the supply chain, or in some examples, between potential organizations that may be added to the supply chain. In particular, the flowing of data requests through the security subsystem, as well as the relationship filtering and data editing achieved by the security subsystem and the trusted store, ensures that no user or organization can access data that they do not have permission to view, update, or delete.

[0150] For example, traditional role-based security mechanisms often assume that data access is granted with a fixed list of users or user groups receiving access. Embodiments provide access based on the "relationship between data owner and data consumer." For example, when access to a piece of data is granted to a "customer" of an organization, the organizations granted access to the piece of data may dynamically change as the business relationship is updated, since the organizations that fall into the "customer" category may dynamically change. Embodiments provide authorization policies that can efficiently and effectively protect data retrieval in the presence of such changes. Additionally, traditional security is often record key-based. Embodiments include finer granularity where security is set independently on each field of a record.

[0151] FIG. 15 illustrates an example method for managing a network of nodes using delta processing, according to an example embodiment. In an embodiment, the following functions of FIG. 15 and FIG. 16 are implemented by software stored in memory or other computer-readable or tangible medium and executed by a processor. In other embodiments, the functions may be performed by hardware (e.g., through the use of application specific integrated circuits ("ASICs"), programmable gate arrays ("PGAs"), field programmable gate arrays ("FPGAs"), etc.), or by any combination of hardware and software.

[0152] At 1502, a network having a plurality of connected nodes is stored, where the nodes represent entities of the network. For example, the network of connected nodes may be mapped onto a relational data table. In an embodiment, the network may be a social network represented by a directed graph.

[0153] At 1504, one or more deltas for the network may be received indicating updates to connections between multiple nodes. For example, updates to network information may be received from an authenticated user associated with an entity of the network, and one or more deltas may be generated based on the updates. At 1506, the deltas may be added to a queue. At 1508, connections between nodes of the network may be updated with the deltas from the queue. For example, the queue may be a FIFO queue, and the deltas at the head of the queue may be processed to update the network.

[0154] At 1510, the network may be processed after updating the connections between the nodes to generate vectors for a given node. For example, the transitive closure for the network may be determined after updating the network, and the transitive closure may be used to generate direct access vectors for each node in the network.

[0155] In some embodiments, the drip-feed delta processing may include storing a pre-computed version of the network data in a set of relational data tables. The pre-computed version may provide efficient traversal of the network, for example, based on the pre-computed network data stored in the data tables. In some embodiments, processing the network may include updating data in one or more of the data tables that store the pre-computed version of the network data. In some embodiments, the pre-computed version of the network data provides direct access vectors for nodes of the network that may be retrieved by querying the data tables. The direct access vectors may indicate connected nodes that include connections with a given node and indirect nodes that are part of a path that includes the given node and at least one connected node.

[0156] At 1512, one or more paths for a given node may be identified based on the generated vector. For example, a relational data table may be queried using the direct access vector to return path information for a given node. In an embodiment, updating links between nodes of the network may create an identified path that includes the given node.

[0157] In an embodiment, one or more portions and one or more procedures including the portions may be defined for nodes of the network, and a connection between two nodes of the network may be based on a correspondence between a procedure defined for a first of the two nodes that matches a portion defined for a second of the two nodes. For example, a procedure may be a recipe and a portion may be an ingredient for the recipe. In an embodiment, the entities may include suppliers and customers, and the connections may represent transactions between the entities. For example, the identified paths may represent a supply chain for at least one commodity or product. In an embodiment, a transitive closure may be determined with the connections of the network based on the correspondence between the procedures and portions for the connected nodes.

[0158] 16 illustrates an example method for providing secure data management for a network of nodes, according to an example embodiment. At 1602, a network including a plurality of connected nodes is stored, where the nodes represent entities of the network. For example, the network of connected nodes may be mapped onto a relational data table. In an embodiment, the network may be a social network represented by a directed graph.

[0159] At 1604, a request may be received from a first node to retrieve data related to a second node of the network. For example, the request may be received from an authorized user of the entity represented by the first node. At 1606, a query may be generated to retrieve the requested data.

[0160] At 1608, the query may be filtered based on permissions for the first node stored in the trusted store. For example, the query may be expanded with a key used to retrieve the requested data based on permissions for the first node associated with the second node stored in the trusted store.

[0161] In some embodiments, a permission file is stored that defines access to one or more of the relational data tables, and access permissions are defined for each record in the relational data table based on an owner node that owns the record and a relationship between the owner node and the node requesting access. The trusted store can immutably store a plurality of keys for nodes of the network. In some embodiments, filtering the query based on permissions for a first node stored in the trusted store includes accessing the permission file to retrieve a list of keys from the trusted store, the list of keys being for a subset of nodes that are permitted for access by the first node according to a relationship between the first node and the subset of nodes. Expanding the query can include adding a list of keys to the query, and when the list of keys includes a key corresponding to a protected record, a protected record in the relational data table requested by the query is retrieved.

[0162] In an embodiment, an authenticated user has permission to view at least some data for a node connected to a first node, the first node being connected to a second node. In an embodiment, an authenticated user has permission to view at least some data for a node with a path to the first node, the first node being on a path to the second node.

[0163] At 1610, fields may be redacted from the filtered query results based on permissions for the first node. For example, a permissions file may be accessed to determine what access permissions the first node has in relation to the owner of the records being returned. Any column level data determined to be inaccessible to the first node may be removed before returning the query results. At 1612, the redacted results may be provided to the first node.

[0164] In an embodiment, the entities represented by the nodes may be suppliers and customers, and the paths between the nodes may represent a supply chain network for one or more products. For example, an authenticated user may have authorization to access a supply chain network that includes the first node, that includes a supplier to the first node, or that includes a customer of the first node.

[0165] An embodiment manages data processing for a network of nodes. An exemplary network may include multiple nodes with multiple connections between the nodes. In some embodiments, the network may be a social network with various degrees of information sharing. From time to time, a new connection may be created between two nodes that were not previously connected, or a connection may be broken between nodes that were previously connected. One or more paths may be identified based on the current configuration of the network (e.g., the current connections between the nodes). For example, a path may start at a first node and proceed through a second, third, and fourth node before terminating at a fifth node. Such identified paths may be useful for identifying patterns, trends or risks, making predictions, or for other analytical purposes (i.e., depending on the nodes in the network and the particular embodiment).

[0166] However, the dynamic nature of these networks introduces risks and computational challenges. For example, social networks are often changing, establishing new node connections and disconnecting old ones. Therefore, identifying paths between nodes can be computationally intensive. As further detailed herein, embodiments leverage drip-feed delta processing to manage the network to achieve computational efficiency while maintaining dynamic update capabilities for node connections.

[0167] In some embodiments, entities (e.g., nodes) of the network may have authorized users that interact with the system. For example, authorized users may edit profiles for the entity, send messages to other entities of the network, modify relationships with other entities, retrieve data related to the entities of the network, perform network analysis and other suitable functions. However, in some embodiments, confidential or sensitive information for one or more entities may be stored in association with the network (e.g., in a data store). For example, in a social network, the system may store sensitive information for a first entity that may be shared with a subset of other entities but not with the remaining entities. In other examples, the sensitive information may be marked private and therefore may not be shared with any other entities of the social network.

[0168] In some embodiments, the system can provide secure data retrieval for entities of the network. For example, a security subsystem can maintain one or more permissions for authorized users that determine what information the users can retrieve. Based on the security subsystem, data retrieval requests can be filtered to ensure that authorized users are provided only with information in accordance with the established permissions. For example, relationship filtering can be used to filter queries generated in accordance with permissions before performing a search on a data store. In another example, data redaction can be performed on data retrieved by a query in accordance with permissions to edit the data before providing the data to authorized users. The security subsystem, relationship filtering, and data redaction can be used to ensure secure data management of sensitive or confidential data for entities of the network.

[0169] The features, structures, or characteristics of the disclosure described throughout this specification may be combined in any suitable manner in one or more embodiments. For example, the use of "an embodiment," "some embodiments," "certain embodiment," "certain embodiment," or other similar words throughout this specification refers to the fact that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the disclosure. Thus, the appearance of the phrases "an embodiment," "some embodiments," "certain embodiment," "certain embodiment," or other similar words throughout this specification do not necessarily all refer to the same group of embodiments, and the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0170] Those skilled in the art will readily appreciate that the above-described embodiments may be implemented with steps in a different order and / or with elements in a different configuration than that disclosed. Thus, while this disclosure contemplates the embodiments outlined, certain modifications, variations and alternative configurations will be apparent to those skilled in the art while remaining within the spirit and scope of the disclosure. Therefore, reference should be made to the appended claims to determine the metes and bounds of the disclosure.< / connection> < / organisations>

Claims

1. 1. A method for managing a network of nodes representing a supply chain, the method comprising: The method includes a processor storing a network including a plurality of connected nodes, the nodes representing suppliers and customers, and paths between the connected nodes representing a supply chain of one or more products, the method comprising: receiving a request from an authenticated user of a first node of the network to obtain data relating to a second node of the network; and generating a query to retrieve the requested data from a data table of a secure database storing the network, the first node being connected by one or more paths including a subset of the connected nodes, and the authenticated user of the first node having permissions to access data relating to the subset of the connected nodes, the method comprising: and wherein the processor provides results of the query to the first node if the access permission of the authenticated user of the first node allows access to data related to the second node, and wherein the authenticated user of the first node is allowed to access data related to the second node if the first node and the second node are on a path representing a supply chain.

2. The method of claim 1, further comprising the processor filtering the query based on permissions for the first node stored in a trusted store by extending the query with security parameters providing record-level access to the secure database.

3. 3. The method of claim 2, wherein the security parameters used to expand the query include one or more keys, and the secure record in the data table requested by the query is retrieved if the one or more keys include a key that corresponds to a secure record.

4. The method of claim 3 , wherein the one or more keys used to expand the query are based on permissions for the first node associated with the second node.

5. 5. The method of claim 1, wherein the data tables of the secure database maintain a pre-computed version of the network configured to return one or more routes for the first node based on a relational query.

6. 6. The method of claim 5, wherein the pre-computed version of the network is maintained by queuing deltas representing changes to the plurality of connected nodes and updating the data tables of the secure database by processing the queued deltas.

7. the network including the plurality of connected nodes comprises a social graph; The method of claim 5 , wherein the pre-computed version of the network includes the social graph mapped to the data tables of the secure database.

8. One or more ingredients and one or more recipes including the ingredients are defined for the plurality of connection nodes; 6. The method of claim 5, wherein a connection between two nodes of the network is based on a correspondence between an ingredient defined for a second of the two nodes and a recipe defined for a first of the two nodes that matches the ingredient.

9. The precomputed version of the network is maintained by determining the transitive closure of the network; The method of claim 8 , wherein the transitive closure is determined based on correspondences between recipes and ingredients of the plurality of connected nodes with connections between the plurality of connected nodes.

10. A computer readable program for causing a processor to carry out the method according to any one of claims 1 to 9.

11. 1. A system comprising: a processing device in communication with the memory device, the processing device configured to manage a network of nodes representing a supply chain, the managing comprising: storing a network including a plurality of connected nodes, the nodes representing suppliers and customers, and paths between the connected nodes representing a supply chain of one or more products; receiving a request from an authenticated user of a first node of the network to obtain data relating to a second node of the network; and generating a query to retrieve the requested data from a data table of a secure database that stores the network, the first node being connected by one or more paths that include a subset of the connected nodes, and the authenticated user of the first node having permissions to access data relating to the subset of the connected nodes, the managing comprising: providing results of the query to the first node if the access permission of the authenticated user of the first node allows access to data relating to the second node, wherein if the first node and the second node are on a path representing a supply chain, the authenticated user of the first node is allowed to access data relating to the second node.

Images