Patent Application
20240193138
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
The field relates generally to information processing systems, and more particularly to techniques for data management using such systems.
Digital assets and information related thereto are increasingly created and/or shared between various enterprise-related entities such as applications and databases. Using conventional data management approaches, such digital assets and information are typically generated and managed by various entities across multiple distributed systems, and are not linked. Such conventional data management approaches are therefore fragmented and create issues related, for example, to data security, data accuracy, and data visibility.
Illustrative embodiments of the disclosure provide techniques for generating and processing digital asset information chains using machine learning techniques.
An exemplary computer-implemented method includes obtaining data, from one or more data sources, pertaining to one or more events involving a digital asset, and generating a digital asset information chain associated with the digital asset by processing at least a portion of the obtained data using at least one cryptographic function and linking that at least a portion of the obtained data in accordance with at least one temporal parameter. Also, the method includes performing anomaly detection by processing at least a portion of the digital asset information chain associated with the digital asset using one or more machine learning techniques. Further, the method additionally includes performing one or more automated actions based at least in part on one or more of the digital asset information chain and results from the anomaly detection.
Illustrative embodiments can provide significant advantages relative to conventional data management approaches. For example, problems associated with data security, data accuracy, and data visibility are overcome in one or more embodiments through automatically producing and processing digital asset information chains using one or more machine learning techniques.
These and other illustrative embodiments described herein include, without limitation, methods, apparatus, systems, and computer program products comprising processor-readable storage media.
Illustrative embodiments will be described herein with reference to exemplary computer networks and associated computers, servers, network devices or other types of processing devices. It is to be appreciated, however, that these and other embodiments are not restricted to use with the particular illustrative network and device configurations shown. Accordingly, the term “computer network” as used herein is intended to be broadly construed, so as to encompass, for example, any system comprising multiple networked processing devices.
The user devices 102 may comprise, for example, mobile telephones, laptop computers, tablet computers, desktop computers or other types of computing devices. Such devices are examples of what are more generally referred to herein as “processing devices.” Some of these processing devices are also generally referred to herein as “computers.”
The user devices 102 in some embodiments comprise respective computers associated with a particular company, organization or other enterprise. In addition, at least portions of the computer network 100 may also be referred to herein as collectively comprising an “enterprise network.” Numerous other operating scenarios involving a wide variety of different types and arrangements of processing devices and networks are possible, as will be appreciated by those skilled in the art.
Also, it is to be appreciated that the term “user” in this context and elsewhere herein is intended to be broadly construed so as to encompass, for example, human, hardware, software or firmware entities, as well as various combinations of such entities.
The network 104 is assumed to comprise a portion of a global computer network such as the Internet, although other types of networks can be part of the computer network 100, including a wide area network (WAN), a local area network (LAN), a satellite network, a telephone or cable network, a cellular network, a wireless network such as a Wi-Fi or WiMAX network, or various portions or combinations of these and other types of networks. The computer network 100 in some embodiments therefore comprises combinations of multiple different types of networks, each comprising processing devices configured to communicate using internet protocol (IP) or other related communication protocols.
Additionally, digital asset information chain generation system 105 can have an associated digital asset information repository 106 configured to store data pertaining to various digital assets, which comprise, for example, order-related information, manufacturing-related information, support-related information, enterprise application-related information, etc.
The digital asset information repository 106 in the present embodiment is implemented using one or more storage systems associated with digital asset information chain generation system 105. Such storage systems can comprise any of a variety of different types of storage including network-attached storage (NAS), storage area networks (SANs), direct-attached storage (DAS) and distributed DAS, as well as combinations of these and other storage types, including software-defined storage.
Also associated with digital asset information chain generation system 105 are one or more input-output devices, which illustratively comprise keyboards, displays or other types of input-output devices in any combination. Such input-output devices can be used, for example, to support one or more user interfaces to digital asset information chain generation system 105, as well as to support communication between digital asset information chain generation system 105 and other related systems and devices not explicitly shown.
Additionally, digital asset information chain generation system 105 in the
More particularly, digital asset information chain generation system 105 in this embodiment can comprise a processor coupled to a memory and a network interface.
The processor illustratively comprises a microprocessor, a central processing unit (CPU), a graphics processing unit (GPU), a tensor processing unit (TPU), a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other type of processing circuitry, as well as portions or combinations of such circuitry elements.
The memory illustratively comprises random access memory (RAM), read-only memory (ROM) or other types of memory, in any combination. The memory and other memories disclosed herein may be viewed as examples of what are more generally referred to as “processor-readable storage media” storing executable computer program code or other types of software programs.
One or more embodiments include articles of manufacture, such as computer-readable storage media. Examples of an article of manufacture include, without limitation, a storage device such as a storage disk, a storage array or an integrated circuit containing memory, as well as a wide variety of other types of computer program products. The term “article of manufacture” as used herein should be understood to exclude transitory, propagating signals. These and other references to “disks” herein are intended to refer generally to storage devices, including solid-state drives (SSDs), and should therefore not be viewed as limited in any way to spinning magnetic media.
The network interface allows digital asset information chain generation system 105 to communicate over the network 104 with the user devices 102, and illustratively comprises one or more conventional transceivers.
The digital asset information chain generation system 105 further comprises digital asset information builder 112, machine learning-based anomaly detection engine 114, and automated action generator 116.
It is to be appreciated that this particular arrangement of elements 112, 114 and 116 illustrated in the digital asset information chain generation system 105 of the
At least portions of elements 112, 114 and 116 may be implemented at least in part in the form of software that is stored in memory and executed by a processor.
It is to be understood that the particular set of elements shown in
An exemplary process utilizing elements 112, 114 and 116 of an example digital asset information chain generation system 105 in computer network 100 will be described in more detail with reference to the flow diagram of
Accordingly, at least one embodiment includes generating and processing digital asset information chains using machine learning techniques. As further detailed herein, such an embodiment includes generating and/or implementing an enterprise asset data composition framework for facilitating intelligent searching, sharing, authenticity verification and fraud detection. Such an embodiment includes generating and/or building a digital asset information custodian framework that composes and links various data generated and managed by one or more entities and/or applications. As used herein, an “enterprise asset” can be defined as a type of digital asset (e.g., a digital asset associated with a given enterprise). Moreover, digital assets can generally include information such as, for example, entity-related metadata (e.g., order information, customer information, etc.).
In at least one embodiment, generating the framework includes providing one or more enforcements of security and privacy, as well as providing timestamp information and application programming interface-based (API-based) searching and sharing of data by leveraging at least one federated smart contract-enabled graph database. Additionally or alternatively, one or more embodiments includes using machine learning techniques to predict anomalies in the digital asset management, for example, for use in connection with fraud detection and prevention.
Also, at least one embodiment includes linking, via the generated framework, data and/or information about various events (e.g., transactional events) of a given enterprise asset as federated data elements, and storing such linked data in a graph database for improved accessibility and smart search capabilities. As noted above and further described herein, at least one embodiment also includes leveraging timestamping of each event record to establish precedency and legitimacy, as well as implementing certified authority-signed (CA-signed) records, multi-party authentication (wherein both the system of record and other stakeholders allow the data-related action), and one or more hashing techniques to link data to ensure authenticity and integrity of the lifecycle event chain of digital information associated with the given enterprise asset. As used herein, a stakeholder refers to an entity, person, and/or application that interacts with a given digital asset. For example, when a customer creates an order using an enterprise sales application, the enterprise sales application can be considered a stakeholder.
One or more embodiments, to assist in preserving such authenticity and integrity of transactions, include detecting anomalies using one or more machine learning techniques (e.g., supervised learning techniques such as autoencoders (using artificial neural networks), support vector machines (SVMs), etc., semi-supervised learning techniques (e.g., one class SVM, etc.), and unsupervised learning techniques (e.g., isolation forest models, k-means algorithms, k-nearest networks (KNN), etc.). This capability enables the framework to build a secure, federated set of touchpoint data, while also allowing access as well as predictive capabilities for fraud detection and prevention.
One or more embodiments include generating and/or implementing a federated and/or decentralized framework to store, manage and access enterprise digital asset lifecycle information by capturing data elements of each access and transformations in the enterprise asset's lifecycle. In addition to providing authenticity, chain of custody, and verification of secure data, such an embodiment includes enabling an API-based search for smart data access and predictive capabilities to detect fraud in the enterprise asset's lifecycle. By linking the data created and managed in various enterprise applications and databases, such an embodiment includes providing a digital asset information wallet for end-to-end access, tracing, searching and/or sharing in a secure manner.
Accordingly, as an enterprise asset is involved in various events and/or stages in its lifecycle from creation to transformation to passing to other applications and databases, secured vignettes of transactions related thereto are created with metadata and/or details pertaining, for example, to the identity of the stakeholder entity, the type of transactional event, etc. In at least one embodiment, such data elements or information vignettes are created after approval from the system of record (e.g., an enterprise application and/or application database) and ensured by using a CA in a secure sockets layer (SSL) manner. By way of example, in one or more embodiments, a CA vouches for the stakeholder and/or enterprise involved in a transaction for enhanced security. For instance, when a stakeholder adds an element to the digital asset information chain, securing and validating that transaction with their certificate from a CA increases the trust in that transaction. Such data can also be secured and rendered access-limited (e.g., ensuring authenticated access to the data), and in one or more embodiments, a hashed digest of the data is stored to limit and/or preclude tampering. Additionally, such an embodiment includes linking at least a portion of (e.g., all of) the data elements to form a digital asset information event chain of the given enterprise asset.
In one or more embodiments, the generated framework stores and manages a transaction list of enterprise digital assets in at least one graph database for ease of access and traversal. Such an embodiment includes utilizing a data query and manipulation language for APIs (e.g., GraphQL) to enable secure, API-based access to transaction data across the lifecycle of an enterprise asset. As fraud in digital assets (e.g., unauthorized access, tampering, etc.) becomes more prevalent, such an embodiment includes leveraging one or more auto-encoders to detect transactional-based fraud across the lifecycle of any enterprise digital asset. Such capabilities can be achieved, for example, by implementing a digital asset information builder, a digital asset information repository, and a machine learning-based anomaly detection engine, such as further detailed in connection with
As further detailed herein, digital asset information chain generation system 205 stores and manages at least a portion of such information using digital asset information repository 206, which can include at least one graph database. In at least one embodiment, such a graph database can utilize at least one API query language (e.g., GraphQL) to enable secure API-based access (e.g., via access-related API 235) to event data across the lifecycle of a given enterprise digital asset. Additionally, one or more embodiments include, via machine learning-based anomaly detection engine 214, leveraging one or more auto-encoders and at least one specialized neural network engine to detect fraud across the lifecycle of a given enterprise digital asset.
Such capabilities can be achieved, as depicted in the example embodiment of
Digital asset information builder 212 is responsible for building foundational data elements of a given enterprise digital asset at each of one or more touchpoints of the digital asset lifecycle. In one or more embodiments, digital asset information builder 212 creates time-stamped, identity-verified records with details on the touchpoints in question (e.g., people and/or entities involved, activities involved, location information, etc.). For example, in an order lifecycle, various events can occur including passing of order data, access of order data, etc. and various updates and/or transformations to at least one entity can occur in one or more different enterprise applications and/or databases.
Each such event, update and/or transformation can result in the creation of at least one separate record of at least one corresponding interaction as a new data entity and/or record by digital asset information builder 212 with information provided by one or more the stakeholders (e.g., one or more applications that access and use the entity). Also, in at least one embodiment, such independent records are differentiated from each other using unique digital fingerprints and/or hashes. For example, any time there will be a new record created for the individual, a hash of the record will be created which will be used for linking the records and creating the chain/list. The hash of the previous record is also stored as part of the current record to ensure anti-tampering. Also, the unique digital fingerprint is that hash of the record which can be created, e.g., using a SHA512 algorithm and parsing data of the record. In addition to providing data security, such digital fingerprints and/or hashes can be used to link records and/or entities to build an end-to-end digital asset information list and/or collection for the given enterprise digital asset.
Accordingly, in one or more embodiments, every individual touchpoint in the digital asset's lifecycle is documented as a record entity, with pertinent information about the identity of the stakeholder (e.g., an enterprise application or an enterprise database), date, time, role, and/or other details of the interaction such as, for example, type (e.g., access, update, transformation, etc.), in a data object. Such a digital asset event record is then added to a digital asset information list and/or collection that links all other records of the same digital asset and/or entity. The link, in at least one embodiment, is achieved by creating a unique message digest (e.g., a hash) of the previous lifecycle event record and storing the message digest in the current record. Such an embodiment also includes storing the hash of the current record in conjunction with and/or as part of the current record, which ensures that each lifecycle event record is immutable and cannot be subsequently changed improperly. An example of such an interaction is represented in
As depicted in
The example pseudocode 400 illustrates hashing of event records using a SHA256 algorithm. However, it should be noted that the SHA256 algorithm shown in example pseudocode 400 represents merely one example cryptographic algorithm that can be utilized, and one or more embodiments can include using other hashing algorithms such as, for instance, SHA512, RIPEMD, Whirlpool, etc.
It is to be appreciated that this particular example pseudocode shows just one example implementation of hashing event records, and alternative implementations can be used in other embodiments.
The example pseudocode 500 illustrates creation of a digital asset information list/chain (e.g., upon initiation of an order in an order management system) and defining the first record for the enterprise asset in the digital asset information list. In one or more embodiments, the first record is also referred to as the genesis record.
It is to be appreciated that this particular example pseudocode shows just one example implementation of creating a genesis record, and alternative implementations can be used in other embodiments.
The example pseudocode 600 illustrates creation of a new event record and adding such a record to a digital asset information list/chain. For example, when a touchpoint with a stakeholder occurs (e.g., a manufacturing system and/or supply chain system accesses an order), a new event record is created and added to the digital asset information list/chain for that enterprise asset.
It is to be appreciated that this particular example pseudocode shows just one example implementation of creating a new event record, and alternative implementations can be used in other embodiments.
The example pseudocode 700 illustrates that at any stage in a given digital asset's lifecycle, a previous record (e.g., the last or preceding record) of the digital asset information list/chain can be retrieved (along with corresponding details), which helps in tracking the progress and providing a status related to the enterprise asset.
It is to be appreciated that this particular example pseudocode shows just one example implementation of retrieving a previous record, and alternative implementations can be used in other embodiments.
The example pseudocode 800 illustrates steps involved in ensuring accuracy and integrity of the interactions documented on a digital asset information list/chain. Specifically, to confirm one or more details of generated records, example pseudocode 800 includes verifying the identity (e.g., the hash) and the index of a given record, as well as verifying the sequence of the interaction(s) and generating an alert upon identifying and/or determining any missing or incorrect data.
It is to be appreciated that this particular example pseudocode shows just one example implementation of performing information verification, and alternative implementations can be used in other embodiments.
Referring again to
As further detailed herein, one or more embodiments can include storing and retrieving information as a graph using a resource description framework (RDF) and/or a labeled property graph (LPG). RDF formats the information (e.g., entity information and relationship information) as a triple (e.g., subject-predicate-object). By way merely of example, information pertaining to a manufacturing application accessing an order entity from an order management system is stored as follows: Subject (Manufacturing)→Predicate (Accesses)→Object (Order). In at least one embodiment, the subject will represent a resource or node/entity in the graph, the predicate will represent an edge in the graph (e.g., a relationship), and the object will represent another node in the graph. These nodes and edges are identified by at least one uniform resource identifier (URI), which represents at least one unique identifier. Also, in one or more embodiments, the nodes and edges do not have any internal structure; the URI labels them. This type of model is efficient, for example, for data exchange.
In an LPG type of graph, each entity is represented as a node with a uniquely identifiable identifier (ID) and a set of key-value pairs and/or properties that characterize the pairs. In one or more embodiments, the relationship between two entities is described as an edge or connection between the nodes. Relationships have an ID to identify the relationships as well as the corresponding relationship type. In at least one embodiment, relationships also have a set of key-value pairs as properties that characterize the connections. This type of structure provides a robust internal design for the entities and relationships, and also facilitates and/or enhances the storage and querying of information.
One or more embodiments include maintaining information pertaining to all interactions and contents of a digital asset information repository in an LPG format because of the efficiency and performance of storing and querying information in a property graph format (e.g., via ArangoDB, Apache TinkerPop, Titan, Neo4J, etc.). Such graph stores are utilized as the platform for a digital asset information repository to store, manage, and query data relationships. In at least one embodiment, a graph database enables the repository (e.g., digital asset information repository 206) to traverse and analyze any level of depth (e.g., in real-time), as well as to add context and connect new data on the fly. Such capabilities can provide a foundation for maintaining end-to-end lifecycle information for enterprise asset events in a single place for future interactions, which enables an efficient mechanism to search the information captured in the graph in a meaningful manner.
Additionally, as detailed herein and in connection with one or more embodiments, NoSQL databases provide a multitude of query languages (e.g., Gremlin, Cypher, SPARQL, Graphene, etc.) to retrieve entities and/or concepts, as well as relationships.
Referring again to
Anomaly detection includes a mechanism for identifying situations and/or data instances that are not considered normal based on the observation of one or more properties being considered. Digital asset information list/chain anomaly detection can be achieved by leveraging anomaly detection mechanisms via machine learning techniques embodied within a detection engine (e.g., machine learning-based anomaly detection engine 214). For example, in at least one embodiment, a machine learning-based anomaly detection algorithm learns from historical data pertaining to one or more interactions and data exchanges from stakeholders in the enterprise asset (e.g., a product) lifecycle, and by measuring and/or analyzing the behaviors and corresponding relationships thereof, the anomaly detection engine can predict when the state is normal and when the state is anomalous.
By way merely of example, one or more embodiments can include using machine learning algorithms such as at least one unsupervised decision tree-based shallow learning algorithm (e.g., an isolation forest model), at least one deep learning algorithm, etc. For instance, an example embodiment can include implementing multi-variate anomaly detection using an isolation forest model. In such an embodiment, the isolation forest model has the capacity to scale-up to handle extremely large data sizes and high-dimensional problems with a large number of attributes, some of which may be irrelevant and potential noise. The isolation forest model also has a low linear time complexity and is efficient in dealing with masking and swamping effects in anomaly detection. More specifically, implementing an isolation forest model includes isolating an anomaly by creating decision trees over random attributes. This random partitioning can produce significantly shorter paths (than other algorithms) because fewer instances of anomalies result in smaller partitions, and distinguishable attribute values are more likely to be separated in early partitioning. Accordingly, when a forest (i.e., a group) of random trees collectively produces shorter path lengths for some particular points, then such points are highly likely to be anomalies.
In one or more embodiments, a given number of splits are required to isolate a normal point while an anomaly can be isolated by a reduced and/or smaller number of splits. The number of splits determines the level at which the isolation occurs, and can be used to generate a corresponding anomaly score. One or more embodiments include using an isolation forest model, which uses a splitting model for isolating and/or detecting anomalous data. The scores are generated by the algorithm based on how many splits are needed to isolate. The fewer the number of splits to isolate indicates anomalous data, and more splits indicates normal data. Such a process can be repeated multiple times, with the isolation level of each point being noted. Once an iteration is over, the anomaly score of each point/instance suggests the likelihood of an anomaly. In at least one embodiment, the anomaly score is a function of the average level at which the point is isolated, and the top points/instances gathered on the basis of the score are labeled as anomalies.
The example pseudocode 900 illustrates parameters (e.g., digital asset information role, type information, etc.) which are periodically collected from stakeholders and input to the anomaly detection engine for processing and/or prediction. An isolation forest model, already trained using historical pattern data, processes this input to generate a prediction, and if the model identifies a given parameter value as deviating from typical values, the model predicts and identifies the state as an anomaly. As depicted in
It is to be appreciated that this particular example pseudocode shows just one example implementation of determining an anomaly score, and alternative implementations can be used in other embodiments.
Architecturally, as depicted in
In at least one embodiment, and within the context of anomaly detection, autoencoder network 1014 compresses data (e.g., enterprise asset information) to a lower dimensional representation, which will result in capturing correlations and interactions between various variables and/or parameters. The autoencoder network 1014 is then trained using data from normal operating states of the stakeholders (e.g., enterprise applications, enterprise databases, etc.), subsequently compressing and then reconstructing at least a portion of the input variables.
During the dimensionality reduction, the autoencoder network 1014 learns one or more interactions between various variables and reconstructs data back to the original variables at the output. If a fraud scenario is identified and/or appears in connection with one of the stakeholders, such fraud would likely affect the interaction between at least a portion of the variables. In such a scenario, the number of errors tends to increase in the reconstruction of the networks input variables. By utilizing a probability distribution of the reconstruction error, the autoencoder network 1014 identifies whether a sample data point (e.g., a touchpoint with a stakeholder) is normal or anomalous. Based on the decision from autoencoder network 1014, anomalous behaviors can be identified and alerted to initiate one or more corrective actions.
By way merely of example, at least one embodiment can be implemented as a deep learning algorithm (e.g., ANN, long short-term memory (LSTM), one or more transformers, and/or other neural network-based algorithms) on Python with Keras and TensorFlow backend. For instance, such an embodiment can include a three-layer network implemented using Keras and/or TensorFlow libraries, with approximately 10-12 nodes in the input and output layers. Additionally, in such an embodiment, a mean squared error can be used as a loss function and Adam, an adaptive optimized algorithm, can be used for stochastic optimization. It should be noted, however, that such algorithms are identified merely as examples, and one or more embodiments can include using and/or modifying one or more algorithms as part of hyper-parameter search and tuning activities to reach enhanced model performance and accuracy.
It is to be appreciated that some embodiments described herein utilize one or more artificial intelligence models. It is to be appreciated that the term “model,” as used herein, is intended to be broadly construed and may comprise, for example, a set of executable instructions for generating computer-implemented recommendations and/or predictions. For example, one or more of the models described herein may be trained to generate recommendations and/or predictions based on data related to digital assets and/or usage thereof collected from various devices (e.g., user devices 102), and such recommendations and/or predictions can be used to initiate one or more automated actions (e.g., automated fraud detection actions and/or remedial actions related thereto).
In this embodiment, the process includes steps 1100 through 1106. These steps are assumed to be performed by the digital asset information chain generation system 105 utilizing its elements 112, 114 and 116.
Step 1100 includes obtaining data, from one or more data sources, pertaining to one or more events involving a digital asset. In at least one embodiment, obtaining data includes documenting the data as record entities in object data with corresponding information pertaining to one or more of participant identification, date, time, and one or more documents exchanged. Additionally or alternatively, obtaining data can include implementing multi-party authentication, in connection with (i) at least one entity associated with at least one of the one or more data sources and (ii) the digital asset, with respect to the data.
Step 1102 includes generating a digital asset information chain associated with the digital asset by processing at least a portion of the obtained data using at least one cryptographic function and linking that at least a portion of the obtained data in accordance with at least one temporal parameter. In one or more embodiments, processing at least a portion of the obtained data using at least one cryptographic function includes processing at least a portion of the obtained data using at least one hashing algorithm. Additionally or alternatively, processing at least a portion of the obtained data using at least one cryptographic function can include processing at least a portion of the obtained data using at least one message digest algorithm.
In at least one embodiment, generating a digital asset information chain includes, for each of multiple records within the obtained data, creating one of a unique message digest and a hash of a temporally preceding record and storing the unique message digest or hash in conjunction with a temporally subsequent record. Such an embodiment can also include creating one of a unique message digest and a hash of the temporally subsequent record and storing the unique message digest or hash of the temporally subsequent record with the unique message digest or hash of the temporally preceding record.
Step 1104 includes performing anomaly detection by processing at least a portion of the digital asset information chain associated with the digital asset using one or more machine learning techniques. In at least one embodiment, processing at least a portion of the digital asset information chain associated with the digital asset using one or more machine learning techniques includes processing at least a portion of the digital asset information chain associated with the digital asset using at least one unsupervised decision tree-based shallow learning algorithm. Additionally or alternatively, processing at least a portion of the digital asset information chain associated with the digital asset using one or more machine learning techniques can include processing at least a portion of the digital asset information chain associated with the digital asset using at least one deep learning algorithm. Also, in at least one embodiment, processing at least a portion of the digital asset information chain associated with the digital asset using one or more machine learning techniques includes processing at least a portion of the digital asset information chain associated with the digital asset using at least one neural network-based auto-encoder.
Step 1106 includes performing one or more automated actions based at least in part on one or more of the digital asset information chain and results from the anomaly detection. In one or more embodiments, performing one or more automated actions includes storing the digital asset information chain in at least one graph database. In such an embodiment, storing the digital asset information chain in at least one graph database can include implementing permissioned application programming interface-based access to the stored digital asset information chain in connection with at least one application programming interface query language. Additionally or alternatively, storing the digital asset information chain in at least one graph database can include storing the digital asset information chain using at least one of a resource description framework and a labeled property graph.
Also, in one or more embodiments, performing one or more automated actions includes automatically training the one or more machine learning techniques using at least a portion of the results from the anomaly detection.
Accordingly, the particular processing operations and other functionality described in conjunction with the flow diagram of
The above-described illustrative embodiments provide significant advantages relative to conventional approaches. For example, some embodiments are configured to generate and process digital asset information chains using machine learning techniques. These and other embodiments can effectively overcome problems associated with data security, data accuracy, and data visibility.
It is to be appreciated that the particular advantages described above and elsewhere herein are associated with particular illustrative embodiments and need not be present in other embodiments. Also, the particular types of information processing system features and functionality as illustrated in the drawings and described above are exemplary only, and numerous other arrangements may be used in other embodiments.
As mentioned previously, at least portions of the information processing system 100 can be implemented using one or more processing platforms. A given such processing platform comprises at least one processing device comprising a processor coupled to a memory. The processor and memory in some embodiments comprise respective processor and memory elements of a virtual machine or container provided using one or more underlying physical machines. The term “processing device” as used herein is intended to be broadly construed so as to encompass a wide variety of different arrangements of physical processors, memories and other device components as well as virtual instances of such components. For example, a “processing device” in some embodiments can comprise or be executed across one or more virtual processors. Processing devices can therefore be physical or virtual and can be executed across one or more physical or virtual processors. It should also be noted that a given virtual device can be mapped to a portion of a physical one.
Some illustrative embodiments of a processing platform used to implement at least a portion of an information processing system comprises cloud infrastructure including virtual machines implemented using a hypervisor that runs on physical infrastructure. The cloud infrastructure further comprises sets of applications running on respective ones of the virtual machines under the control of the hypervisor. It is also possible to use multiple hypervisors each providing a set of virtual machines using at least one underlying physical machine. Different sets of virtual machines provided by one or more hypervisors may be utilized in configuring multiple instances of various components of the system.
These and other types of cloud infrastructure can be used to provide what is also referred to herein as a multi-tenant environment. One or more system components, or portions thereof, are illustratively implemented for use by tenants of such a multi-tenant environment.
As mentioned previously, cloud infrastructure as disclosed herein can include cloud-based systems. Virtual machines provided in such systems can be used to implement at least portions of a computer system in illustrative embodiments.
In some embodiments, the cloud infrastructure additionally or alternatively comprises a plurality of containers implemented using container host devices. For example, as detailed herein, a given container of cloud infrastructure illustratively comprises a Docker container or other type of Linux Container (LXC). The containers are run on virtual machines in a multi-tenant environment, although other arrangements are possible. The containers are utilized to implement a variety of different types of functionality within the system 100. For example, containers can be used to implement respective processing devices providing compute and/or storage services of a cloud-based system. Again, containers may be used in combination with other virtualization infrastructure such as virtual machines implemented using a hypervisor.
Illustrative embodiments of processing platforms will now be described in greater detail with reference to
The cloud infrastructure 1200 further comprises sets of applications 1210-1, 1210-2, 1210-L running on respective ones of the VMs/container sets 1202-1, 1202-2, . . . 1202-L under the control of the virtualization infrastructure 1204. The VMs/container sets 1202 comprise respective VMs, respective sets of one or more containers, or respective sets of one or more containers running in VMs. In some implementations of the
A hypervisor platform may be used to implement a hypervisor within the virtualization infrastructure 1204, wherein the hypervisor platform has an associated virtual infrastructure management system. The underlying physical machines comprise one or more information processing platforms that include one or more storage systems.
In other implementations of the
As is apparent from the above, one or more of the processing modules or other components of system 100 may each run on a computer, server, storage device or other processing platform element. A given such element is viewed as an example of what is more generally referred to herein as a “processing device.” The cloud infrastructure 1200 shown in
The processing platform 1300 in this embodiment comprises a portion of system 100 and includes a plurality of processing devices, denoted 1302-1, 1302-2, 1302-3, . . . 1302-K, which communicate with one another over a network 1304.
The network 1304 comprises any type of network, including by way of example a global computer network such as the Internet, a WAN, a LAN, a satellite network, a telephone or cable network, a cellular network, a wireless network such as a Wi-Fi or WiMAX network, or various portions or combinations of these and other types of networks.
The processing device 1302-1 in the processing platform 1300 comprises a processor 1310 coupled to a memory 1312.
The processor 1310 comprises a microprocessor, a CPU, a GPU, a TPU, a microcontroller, an ASIC, a FPGA or other type of processing circuitry, as well as portions or combinations of such circuitry elements.
The memory 1312 comprises random access memory (RAM), read-only memory (ROM) or other types of memory, in any combination. The memory 1312 and other memories disclosed herein should be viewed as illustrative examples of what are more generally referred to as “processor-readable storage media” storing executable program code of one or more software programs.
Articles of manufacture comprising such processor-readable storage media are considered illustrative embodiments. A given such article of manufacture comprises, for example, a storage array, a storage disk or an integrated circuit containing RAM, ROM or other electronic memory, or any of a wide variety of other types of computer program products. The term “article of manufacture” as used herein should be understood to exclude transitory, propagating signals. Numerous other types of computer program products comprising processor-readable storage media can be used.
Also included in the processing device 1302-1 is network interface circuitry 1314, which is used to interface the processing device with the network 1304 and other system components, and may comprise conventional transceivers.
The other processing devices 1302 of the processing platform 1300 are assumed to be configured in a manner similar to that shown for processing device 1302-1 in the figure.
Again, the particular processing platform 1300 shown in the figure is presented by way of example only, and system 100 may include additional or alternative processing platforms, as well as numerous distinct processing platforms in any combination, with each such platform comprising one or more computers, servers, storage devices or other processing devices.
For example, other processing platforms used to implement illustrative embodiments can comprise different types of virtualization infrastructure, in place of or in addition to virtualization infrastructure comprising virtual machines. Such virtualization infrastructure illustratively includes container-based virtualization infrastructure configured to provide Docker containers or other types of LXCs.
As another example, portions of a given processing platform in some embodiments can comprise converged infrastructure.
It should therefore be understood that in other embodiments different arrangements of additional or alternative elements may be used. At least a subset of these elements may be collectively implemented on a common processing platform, or each such element may be implemented on a separate processing platform.
Also, numerous other arrangements of computers, servers, storage products or devices, or other components are possible in the information processing system 100. Such components can communicate with other elements of the information processing system 100 over any type of network or other communication media.
For example, particular types of storage products that can be used in implementing a given storage system of an information processing system in an illustrative embodiment include all-flash and hybrid flash storage arrays, scale-out all-flash storage arrays, scale-out NAS clusters, or other types of storage arrays. Combinations of multiple ones of these and other storage products can also be used in implementing a given storage system in an illustrative embodiment.
It should again be emphasized that the above-described embodiments are presented for purposes of illustration only. Many variations and other alternative embodiments may be used. Also, the particular configurations of system and device elements and associated processing operations illustratively shown in the drawings can be varied in other embodiments. Thus, for example, the particular types of processing devices, modules, systems and resources deployed in a given embodiment and their respective configurations may be varied. Moreover, the various assumptions made above in the course of describing the illustrative embodiments should also be viewed as exemplary rather than as requirements or limitations of the disclosure. Numerous other alternative embodiments within the scope of the appended claims will be readily apparent to those skilled in the art.
