Patent Application
20240411897
In recent years, software applications have increasingly relied on third-party components, many of which are released under open-source license. These components are typically declared as dependencies in the manifest files of the software applications, e.g., by specifying the name and version of the component to be used. Prebuilt open-source components or packages are made available on package registries. Package managers download these prebuilt packages from the registries according to the dependency declarations in the applications' manifest files, making the code included within these packages available in the applications' development or runtime environments.
However, these open-source components often suffer from security vulnerabilities, which can negatively impact the applications that use them, either directly or indirectly. To determine whether a particular application is affected by these vulnerabilities, code-level information about the vulnerability, such as the identifiers of vulnerable functions and the identifiers of components that include those functions, must be identified. Obtaining such information enables developers to employ program analysis techniques, such as static analysis or dynamic analysis, to study the vulnerable component and its use in the context of a given application. For example, reachability analysis, determines whether a particular function that is part of an open-source component can be reached by an application that directly or indirectly uses the particular function.
A significant challenge is that the necessary code-level information for these analyses is typically not included in the security advisories issued by open-source project maintainers or other bodies like the National Vulnerability Database (NVD). This lack of information necessitates providers of security tools or services to enrich public vulnerability information with this code-level information, a time-consuming and complex task. Various methods have been proposed to solve these issues. For example, manual analysis by security experts can provide the necessary information, but this approach is labor-intensive and not scalable. Automated vulnerability scanners can also provide some help, but they often rely on pattern matching or other heuristics that can lead to false positives or negatives. Moreover, these tools typically do not provide the detailed code-level information needed for a thorough analysis.
This Summary provides a simplified form of concepts that are further described below in the Detailed Description. This Summary is not intended to identify key or essential features and should therefore not be used for determining or limiting the scope of the claimed subject matter.
In some examples, a server receives a security advisory that includes a description of a vulnerability and accesses a version control system (VCS) used by a third-party library to determine additional resources related to the vulnerability. The server determines a set of code changes performed by the project maintainers in the VCS, identifies one or more fix commits that address the vulnerability, and identifies one or more functions with the vulnerability that have been changed by the fix commits. The server performs a search for components and component versions that include the one or more functions with the vulnerability and generates an enriched vulnerability description that includes identifiers of package versions that include fixed versions of the one or more functions and vulnerable version of the one or more functions. Project code in a development system is modified to use the fixed versions of the one or more functions.
A more complete understanding of the present disclosure may be obtained by reference to the following Detailed Description when taken in conjunction with the accompanying Drawings. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same reference numbers in different figures indicate similar or identical items.
It should be understood, however, that the following descriptions, while indicating preferred aspects and numerous specific details thereof, are given by way of illustration only and should not be treated as limitations. Changes and modifications may be made within the scope herein without departing from the spirit and scope thereof, and the present invention herein includes all such modifications.
The systems and techniques enhance the security of software applications that use third-party components. The systems and techniques may begin after receiving a vulnerability description from a security advisory, such as those published by the National Vulnerability Database (NVD). The vulnerability description provides a high-level overview of the security issue, including its potential impact and the affected software or hardware. After receiving the vulnerability description, the systems and techniques obtain access to a version control system (VCS) used by open-source maintainers to manage project artifacts. Examples of such VCS include Git and Mercurial. The VCS allows the maintainers to track changes to the source code files and other project artifacts. The systems and techniques may identify additional resources related to the vulnerability. These resources can include issues or tickets from the project's project management system, web resources, or social media posts. The identification of these resources can be done by crawling and searching the internet or by following links in the vulnerability description. Using the reference to the project's VCS, the systems and techniques generate a set of code changes performed by the project maintainers. These code changes may include commits, which include both the actual code changes and metadata, such as author information, a textual summary of the change, and timestamps. The systems and techniques may identify one or more fix commits, e.g., changes that modify the project's source code in such a way that the vulnerability is addressed (e.g., fixed or resolved). The identification of fix commits can be done using various techniques, including machine learning or artificial intelligence (AI). In some cases, the commit message, which is a textual description or summary of the changes, includes the vulnerability identifier or a description of the vulnerability similar to what's described in the vulnerability disclosure. In other cases, the code changes themselves can be analyzed to establish whether a given commit is related to the vulnerability. The systems and techniques may compare the timestamps of the commits and the publication dates of the vulnerability disclosure and the identified additional resources. This comparison can help to reduce the set of candidate commits and to identify those commits that are likely to be related to the vulnerability. Additional resources that can be useful for identifying fix commits include other documents that discuss or describe the vulnerability. These documents can be tickets in project management software, such as Jira, or resources describing how to exploit the vulnerability.
After the fix commits have been identified, the systems and techniques may identify the individual functions that were vulnerable and have been changed to address the vulnerability. This can be done by comparing the files before and after the change, either their textual representation or using various abstractions and representations of source code, such as abstract syntax trees. It is also desirable to exclude functions that are not directly related to the vulnerability. Such functions can be part of fix commits, if the developers performed other changes at the same time and included them in the commit. In other words, the developers did not limit the fix commit to changes related to the vulnerability. The resulting set can include both the signature of functions as well as function bodies or different representations thereof. These representations can include abstract syntax trees, data or control flow graphs, bytecode, or other forms of compiled code. The systems and techniques may take the affected functions as input and search for components and component versions including them. This may be done by obtaining packages from package registries, such as Maven Central or npm, and verifying whether they include the respective function in their vulnerable form or fixed form. Some package registries include a dedicated search function to facilitate this step, while others require downloading and indexing entire registries. In any case, the code part of downloaded packages may be searched for and compared against the affected functions, in order to establish not only whether the function is included, but also whether it is included in the vulnerable form or the fixed form. This comparison can involve the source code representation, abstractions thereof, such as abstract syntax trees or control flow graphs, as well as their compiled form. The systems and techniques may produce as output an enriched vulnerability description, which includes information about the affected functions and the identifiers of package versions that include fixed or vulnerable versions of the affected functions.
The systems and techniques provide several advantages. For example, the systems and techniques allow for a more thorough and accurate identification of vulnerabilities in software applications that use third-party components. The systems and techniques enable developers to quickly identify and fix vulnerabilities, thereby improving (increasing) the security of their applications. The systems and techniques can be implemented in and used with a variety of programming languages, including, for example, Java, C++, Python, and JavaScript. The systems and techniques can be implemented in a variety of computing environments, including desktop computers, servers, cloud computing platforms, and mobile devices. The specific implementation can vary depending on the computing environment and the specific requirements of the software application and the third-party components it uses.
By identifying and addressing vulnerabilities in a timely and accurate manner, the systems and techniques can significantly reduce the risk of security breaches and increase the overall security of software applications. The systems and techniques can also contribute to the ongoing efforts to improve the security of open-source software, by providing a systematic and automated method for identifying and fixing vulnerabilities in open-source components. With the increasing use of open-source software in various industries, the systems and techniques can provide significant benefits in terms of improved security and reduced risk of security breaches.
The systems and techniques described increase the security of software applications that utilize third-party components. The systems and techniques provide a systematic approach to identifying and addressing vulnerabilities in third-party library functions and components. The systems and techniques enrich vulnerability descriptions with detailed code-level information, which is typically absent in existing vulnerability databases. In addition, artificial intelligence (AI) may be used to identify fix commits related to a vulnerability, thereby automating and improving the accuracy of the vulnerability identification process.
For example, enhancing software security may begin by receiving a high-level vulnerability description from a security advisory, such as those published by the National Vulnerability Database (NVD). The systems and techniques then obtain a reference to the version control system (VCS) used by open-source maintainers to manage project artifacts, particularly source code files. Additional resources related to the vulnerability, such as issues or tickets from the project's project management system, may also be identified. In some cases, a set of code changes performed by the project maintainers in the VCS may be identified. These code changes are made through commits, which include both the actual code changes and metadata, such as author information, a textual summary of the change, and timestamps.
The systems and techniques may determine the commits and additional resources and create a set of one or more fix commits. These are the changes that resolve the vulnerability in the project's source code. The identification of fix commits can be done using various techniques, including machine learning or artificial intelligence. In some cases, the commit message includes the vulnerability identifier or a description of the vulnerability. In other cases, the code changes themselves may be analyzed to determine whether a given commit is related to the vulnerability. Using the fix commits as input, the systems and techniques may identify the individual functions that were vulnerable and that have been modified to address the vulnerability. For example, this may done by comparing the files before and after the change, using either their textual representation or using various representations (e.g., abstractions) of source code, such as syntax trees. The systems and techniques may exclude functions that are not directly related to the vulnerability. The resulting set can include both the signature of functions as well as function bodies or different representations thereof. In some cases, the systems and techniques may take the affected functions as input and search for components and component versions that include them. This may be done by obtaining packages from package registries and verifying whether they include the respective function in their vulnerable form or fixed form. The code part of downloaded packages may be searched for and compared against the affected functions, to establish not only whether the function is included, but also whether it is included in the vulnerable or the fixed form. The systems and techniques may produce, as output, an enriched vulnerability description, which includes information about the affected functions and the identifiers of package versions that include fixed or vulnerable versions of the affected functions.
As an example, a server includes one or more processors and one or more non-transitory computer readable media storing instructions executable by the one or more processors to perform various operations. The operations include receiving a security advisory that include a description of a vulnerability. The operations include accessing a version control system (VCS) used by a third-party library. The operations include determining additional resources related to the vulnerability. The operations include determining a set of code changes performed by project maintainers in the VCS. The operations include identifying one or more fix commits that address the vulnerability. The operations include identifying one or more functions with the vulnerability that have been changed by the one or more fix commits. The operations include performing a search for components and component versions that include the one or more functions with the vulnerability. The operations include generating an enriched vulnerability description that includes identifiers of package versions that include: fixed versions of the one or more functions and vulnerable version of the one or more functions. The operations include modifying project code in a development system to use the fixed versions of the one or more functions. The operations may include comparing one or more files corresponding to the one or more functions before and after a code change was made and identifying individual functions of the one or more functions that included the vulnerability and that have been modified to address the vulnerability. The operations may include determining a set of functions that are not directly related to the vulnerability and excluding from the search the set of functions that are not directly related to the vulnerability. The operations may include identifying, using an artificial intelligence, fix commits related to the vulnerability. The operations may include obtaining packages from one or more package registries and determining whether the packages include individual functions of the one or more functions in a vulnerable form or a fixed form. The third-party library may be an open-source library. The security advisory may be received from a security database.
The development system 102 is a software environment that allows software developers to facilitate the creation, modification, and management of the project code 104. The project code 104 includes the source code files of the software project that are managed using a version control system (VCS) 129, such as Git or Mercurial.
The types 106 and dependencies 107 are metadata associated with the project code 104. The types 106 can include information about the data types used in the project code 104, while the dependencies 107 can include information about the other software components that the project code (104) relies on for its functionality.
The compiler 110 is a software tool that transforms the project code 104 into a project binary 112. The project binary 112 is the executable form of the software project that can be run on a computer system. The project function 114 is a specific part of the project code 104 that performs a particular task within the software project.
The 3rd party libraries 116 are software components that are not developed by the project maintainers but are used within the software project to provide certain functionalities. These libraries can include components 118(A), 118(B), 118(C) that provide specific functionalities used by the project code 104.
The commit histories 122 are records of all the code changes performed (e.g., committed to the library) by the third part library maintainers. These changes are done by means of commits 124(1) to 124(N) (N>0), which include both the actual code changes, such as lines added, removed, or changed in the respective source code files, as well as metadata, including information such as author information, a textual summary of the change, timestamps, and the like.
The AI 123 is an artificial intelligence that can be used to identify fix commits (e.g., fix commit 124(M)) that resolve a particular vulnerability. A fix commit is a set of changes to the project's source code to address a vulnerability. The function name 125 is a unique identifier of a function (or set of functions) associated with the fix commit 124(M). The function associated with the function name 125 may include multiple versions 126(1) to 126(P), with each version 126 having a different set of code. The fix commit 124(M) may address a vulnerability 127 included in one or more of the versions 126 of the function name 125.
The other project code 128 and other project binaries (130) are additional software projects that are related to the main software project and included in the development system 102. The relationships 132(1), 132(2), 132(3), 132(4), 132(5), 132(6), 132(7), 132(8) represent various relationships between the project code 104 and the functions 120 in the third-party libraries 116.
The system 100 may receive, as input, an advisory 134 identifying a vulnerability 136 in a function 138 in one of the third-party libraries 116. The system 100 may search for components and component versions that include the vulnerability 136. This may done by obtaining packages from package registries, such as Maven Central or npm, and determining whether they include the function 138 in a vulnerable form (e.g., with the vulnerability 136) or a fixed form (e.g., without the vulnerability 136). This comparison can involve the source code representation, abstractions thereof, e.g. abstract syntax trees or control flow graphs, as well as their compiled form.
The system 100 may produce, as output, an enriched vulnerability description 140, which includes information about the affected functions, e.g., their signatures as well as representations of vulnerable and fixed function bodies, e.g., the source code as found in the VCS 129, or other representations, depending on the programming language in question, e.g. abstract syntax trees, control and data flow graphs, bytecode or compiled code. The identifiers of package versions that include fixed or vulnerable versions of the affected functions may be included in the output. By using the system 100, software developers can enhance the security of their software applications by identifying and resolving vulnerabilities in a more efficient and effective manner.
The system 100 includes the development system 102 used by one or more programmers to create code, such as representative project code 104. The project code 104 is also referred to as source code and is written in a high-level language. The project code 104 may include types 106 that are explicitly defined and implicitly inherited. The project code 104 includes relationships 108 that are explicitly defined and implicitly inherited.
A compiler 110 may be used to compile the project code 104 to create a project binary 112. The project binary 112 may be an intermediate code (e.g., byte code) that is interpreted by a virtual machine, machine level code, or any combination thereof. The project binary 112 may implement at least one project function 114 to provide a particular type of functionality. The development system 102 may include other project code 128 and other project binaries 130 that are compiled versions of the other project code 128. The project code 104 may include dependencies 107 that identify portions of the other project code 128 that depends on (e.g., is called by or calls) the project code 128. The project binary 112 includes the dependencies 107, with portions of the other project binaries 130 depending on (e.g., called by or calling) the project binary 112.
The project function 114 makes a call to one or more components in one or more third-party libraries 116. The one or more third-party libraries 116 may include open-source libraries or other types of libraries. Each component function 120 shown in
For illustration purposes, the project function 114 makes a call 132(1) to component function 120(A1) and a call 132(2) to component function 120(C1). The component function 120(A1) makes a call 132(3) to component function 120(B1) and a call 132(4) to component function 120(C4). The component function 120(C4) makes a call 132(5) to component function 120(B2). The component function 120(C5) makes a call 132(6) to component function 120(B1). The component function 120(C1) makes a call 132(7) to component function 120(C2). The component function 120(C4) makes a call 132(8) to component function 120(C5). The calls made by the component functions (e.g., component function 120(A1)) to other component functions (e.g., component function 120(B1) and component function 120(C4)) are transitive calls from the perspective of the project function 114. For example, the component function 120(B1) is transitively called in two different paths: (1) the path comprising call 132(1) and call 132(3) and (2) the path comprising call 132(1), 132(4), 132(8), and 132(6).
In the example illustrated in
In the flow diagrams of
At 202, the process determines, based on a security advisory, an existence of a vulnerability in a function in a third-party library. For example, in
At 204, the process determines vulnerability data, including function versions associated with the function. For example, in
At 206, the process may determine a commit history associated with the function (that was identified in the security advisory). For example, in
At 208, the process may determine fix commits associated with the function, based on the commit history. For example, in
The fix commits 118 may be used to identify functions 120 affected by the vulnerability 136 and to determine the functions 120 that have been modified to address the vulnerability by one of the commits 124. For example, this may be done by comparing the files before and after a change is made, using either their textual representation or using various abstractions and representations of source code, such as abstract syntax trees. In some cases, functions that are not directly related to the vulnerability 136 may be excluded to keep the data being analyzed to a manageable amount. For example, functions 120 may be included as part of fix commits (e.g., the fix commit 124(M)), if the developers, in addition to providing a fix for the vulnerability, performed other changes at the same time and included them in the commit, e.g., the fix commit was not limited to the vulnerability. A resulting set of functions, such as the representative function name 125, may include both (1) the signature of the respective function, as well as (2) different representations of the functions, such as, for example, abstract syntax trees, data or control flow graphs, bytecode, and the like.
At 210, the process may perform a search to identify components and component versions that include the affected functions (e.g., functions affected by the vulnerability). At 212, the process may search downloaded packages to determine if the function affected by the vulnerability is included and if so which version of the function is included. At 214, the process may determine identifiers of package versions that include fixed or vulnerable versions of the function. For example, in
Thus, the system 100 may augment vulnerability databases using various types of analysis, including reachability analysis. The system 100 may query vulnerability databases for component names of components that include a vulnerability. In many systems, such as the Java ecosystem, code that includes a vulnerability may be copied and used in multiple components with each of the multiple components having different names. Thus, the systems and techniques search third-party libraries for code segments that include known vulnerabilities, including code segments that have been reused in multiple components.
An example of JSON code with a vulnerability is as follows:
A fixed commit is developed by those maintaining a third-party library to resolve issues. In some cases, automated tools (e.g., AI/ML) may be used to search for and identify security-related code changes. Identifying vulnerable code within a project may include extracting components from a fixed commit and determining whether the vulnerability can be reached from an application (e.g., project code). Reachability analysis is used to determine whether a vulnerability is reachable by the application. If the reachability analysis determines that the vulnerability is reachable, the vulnerability is given a higher priority for fixing. The systems and techniques may identify multiple components in the third-party library that include the vulnerability. For example, a database may be searched to find all component identifiers that include vulnerabilities. The systems and techniques may keep track of versions of a component in a third-party library, including a first set of versions that have a vulnerability and a second set of versions that have the vulnerability addressed (e.g., using a committed fix).
Thus, after receiving a vulnerability description the process may produce an enriched vulnerability description, thereby enhancing the security of software applications that use third-party components. The process begins with the receipt of a high-level vulnerability description from a security advisory. This is typically published by the National Vulnerability Database (NVD) or a similar vulnerability alerting system. The vulnerability description provides an initial understanding of the potential security risk associated with a particular software component or function. Vulnerability data is determined by accessing a version control system (VCS) used by open source maintainers to manage project artifacts, such as source code files. Examples of such VCS systems include Git or Mercurial. In addition to the VCS, additional resources related to the vulnerability may be identified, such as issues or tickets from the project's project management system. This information collection can be done starting from links in the vulnerability description, or may include crawling and searching Web resources. The next step in the process involves determining the commit history, e.g., a set of the code changes performed by the project maintainers in the VCS. These code changes are done by means of commits, which include both the actual code changes, such as lines added, removed, or changed in the respective source code files, as well as metadata such as author information, a textual summary of the change, or timestamps. After the commit history is determined, the process moves to the determination of fix commits by identifying one or more fix commits, e.g., those changes that alter the project's source code in such a way that the vulnerability is fixed or resolved. The identification of fix commits can be done using various techniques, including artificial intelligence (AI). The next step in the process involves identifying the component versions. This is done by comparing the files before and after the change, either using their textual representation or using various abstractions and representations of source code, such as abstract syntax trees. In some cases, functions that are not directly related to the vulnerability may be excluded to keep the size manageable. The process may then search downloaded packages by searching for components and component versions that include the functions with the vulnerability. This may be done by obtaining packages from package registries like Maven Central, npm, and the like and verifying whether they include the respective function in their vulnerable or fixed form. The process may determine the identifiers of package versions. The result of the process is an enriched vulnerability description, which includes information about the affected functions and the identifiers of package versions that include fixed or vulnerable versions of the affected functions. The result is a detailed and comprehensive understanding of the vulnerability, its impact, and the necessary steps to address it.
At 302, the process determines, based on a security advisory, an existence of a vulnerability. At 304, the process may analyze a commit history to identify one or more fix commits that address the vulnerability. At 306, for each fix commit that addresses the vulnerability, the process may identify functions (or code segments) affected by the vulnerability. At 308, for each function (or code segment) that is identified as being affected by the vulnerability, the process may determine which versions include the vulnerability. At 310, for each function (or code segment) that is identified as being affected by the vulnerability, determine which versions include a fix to address the vulnerability. At 312, project code in a development system may be modified in such a way that the project code uses the fixed versions of the function and does not use vulnerable version of the function.
For example, in
Thus, a vulnerability is determined after receiving a high-level vulnerability description from a security advisory, such as those published by the National Vulnerability Database (NVD). The version control system (VCS) that is used by the open source maintainers to manage the project artifacts, including source code files, may be obtained. Examples of such VCS include Git or Mercurial. The commit history is analyzed by using the project's VCS to produce a set of the code changes performed by the project maintainers. Such code changes are done by means of commits, which include both the actual code changes, for example, lines added, removed or changed in the respective source code files, as well as metadata such as author information, a textual summary of the change, or timestamps. After analyzing the commit history, the process identifies fix commit functions. The commits and additional resources related to the vulnerability are used to produce a set of one or more fix commits, e.g., changes that modify the project's source code in such a way that the vulnerability is fixed or resolved. The identification of fix commits can be done using various techniques, including using artificial intelligence. In some cases, the commit message, which is a textual description or summary of the changes, includes the vulnerability identifier or a description of the vulnerability similar to what's described in the vulnerability disclosure. Function versions that include the vulnerability are determined, using the fix commits, by identifying the individual functions that were vulnerable and that have been modified to address the vulnerability. For example, the files before and after the change may be compared, either using their textual representation or using various abstractions and representations of source code, such as abstract syntax trees. In some cases, functions not directly related to the vulnerability may be excluded to keep the size manageable. Such functions can be part of fix commits, if the developers performed other changes at the same time and included them in the commit, i.e., they did not limit the fix commit to changes related to the vulnerability. Versions that include the fix may be identified by taking the affected functions searching for components and component versions that include the fix. This may be done by obtaining packages from package registries like Maven Central, npm, or the like and verifying whether they include the respective function in their vulnerable or fixed form. Some package registries include a dedicated search function to facilitate this step, while others require downloading and indexing entire registries. The code part of downloaded packages need to be searched for and compared against the affected functions, in order to establish not only whether the function is included, but also whether it is included in the vulnerable or the fixed form. This comparison can involve the source code representation, abstractions thereof, such as abstract syntax trees or control flow graphs, as well as their compiled form. This produces the enriched vulnerability description, which includes information about the affected functions and the identifiers of package versions that include fixed or vulnerable versions of the affected functions.
At 402, a machine learning algorithm (e.g., software code that has not yet been trained) may be created by one or more software designers. At 404, the machine learning algorithm may be trained using pre-classified training data 406 (e.g., a portion of the training data 112 that has been pre-classified). For example, the training data 406 may have been pre-classified by humans, by machine learning, or a combination of both. After the machine learning has been trained using the pre-classified training data 406, the machine learning may be tested, at 408, using test data 410 to determine an accuracy of the machine learning. For example, in the case of a classifier, the accuracy of the classification may be determined using the test data 410.
If an accuracy of the machine learning does not satisfy a desired accuracy (e.g., 95%, 98%, 99% accurate), at 408, then the machine learning code may be modified (e.g., adjusted), at 412, to achieve the desired accuracy. For example, at 412, the software designers may modify the machine learning software code to improve the accuracy of the machine learning algorithm. After the machine learning has been tuned, at 412, the machine learning may be retrained, at 404, using the pre-classified training data 406. In this way, 404, 408, 412 may be repeated until the machine learning is able to classify the test data 410 with the desired accuracy.
After determining, at 408, that an accuracy of the machine learning satisfies the desired accuracy, the process may proceed to 414, where verification data 416 may be used to verify an accuracy of the machine learning. After the accuracy of the machine learning is verified, at 414, the result is the trained AI 123 of
The processors 502 are one or more hardware devices that may include a single processing unit or a number of processing units, all of which may include single or multiple computing units or multiple cores. The processors 502 may include a GPU and/or AIPU that is integrated into the CPU or the GPU and/or AIPU may be a separate processor device from the CPU. The processors 502 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, graphics processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processors 502 are configured to fetch and execute computer-readable instructions stored in the memory 504, mass storage devices 512, and other types of non-transitory computer-readable media.
Memory 504 and mass storage devices 512 are examples of non-transitory computer storage media (e.g., memory storage devices) for storing instructions that can be executed by the processors 502 to perform the various functions described herein. For example, memory 504 may include both volatile memory and non-volatile memory (e.g., RAM, ROM, or the like) devices. Further, mass storage devices 512 may include hard disk drives, solid-state drives, removable media, including external and removable drives, memory cards, flash memory, floppy disks, optical disks (e.g., compact disc (CD), digital versatile disc (DVD)), a storage array, a network attached storage, a storage area network, or the like. Both memory 504 and mass storage devices 512 may be collectively referred to as memory or computer storage media herein and include any type of non-transitory media capable of storing computer-readable, processor-executable program instructions as computer program code that can be executed by the processors 502 as a particular machine configured for carrying out the operations and functions described in the implementations herein.
The computing device 500 may include one or more communication interfaces 506 for exchanging data via the network(s) 106. The communication interfaces 506 can facilitate communications within a wide variety of networks and protocol types, such as a representative network 516 that may include wired networks (e.g., Ethernet, DOCSIS, DSL, Fiber, USB etc.) and wireless networks (e.g., WLAN, GSM, CDMA, 802.11, Bluetooth, Wireless USB, ZigBee, cellular, satellite, etc.), the Internet and the like. Communication interfaces 506 can also provide communication with external storage, such as a storage array, network attached storage, storage area network, cloud storage, or the like.
The display device 508 may be used for displaying content (e.g., information and images) to users. Other I/O devices 510 may be devices that receive various inputs from a user and provide various outputs to the user, and may include a keyboard, a touchpad, a mouse, a printer, audio input/output devices, and so forth.
The computer storage media, such as memory 504 and mass storage devices 512, may be used to store software and data as shown in
The systems and computing devices described herein are merely examples suitable for some implementations and are not intended to suggest any limitation as to the scope of use or functionality of the environments, architectures and frameworks that can implement the processes, components and features described herein. Thus, implementations herein are operational with numerous environments or architectures, and may be implemented in general purpose and special-purpose computing systems, or other devices having processing capability. Generally, any of the functions described with reference to the figures can be implemented using software, hardware (e.g., fixed logic circuitry) or a combination of these implementations. The term “module,” “mechanism” or “component” as used herein generally represents software, hardware, or a combination of software and hardware that can be configured to implement prescribed functions. For instance, in the case of a software implementation, the term “module,” “mechanism” or “component” can represent program code (and/or declarative-type instructions) that performs specified tasks or operations when executed on a processing device or devices (e.g., CPUs or processors). The program code can be stored in one or more computer-readable memory devices or other computer storage devices. Thus, the processes, components and modules described herein may be implemented by a computer program product.
Furthermore, this disclosure provides various example implementations, as described and as illustrated in the drawings. However, this disclosure is not limited to the implementations described and illustrated herein, but can extend to other implementations, as would be known or as would become known to those skilled in the art. Reference in the specification to “one implementation,” “this implementation,” “these implementations” or “some implementations” means that a particular feature, structure, or characteristic described is included in at least one implementation, and the appearances of these phrases in various places in the specification are not necessarily all referring to the same implementation.
Although the present invention has been described in connection with several embodiments, the invention is not intended to be limited to the specific forms set forth herein. On the contrary, it is intended to cover such alternatives, modifications, and equivalents as can be reasonably included within the scope of the invention as defined by the appended claims.
The present non-provisional patent application claims priority from (1) U.S. Provisional Application 63/552,793 filed on Feb. 13, 2024, (2) U.S. Provisional Application 63/472,562 filed on Jun. 12, 2023 (3) U.S. Provisional Application 63/472,561 filed on Jun. 12, 2023 and (4) U.S. Provisional Application 63/472,557 filed on Jun. 12, 2023, all of which are incorporated herein by reference in their entirety and for all purposes as if completely and fully set forth herein.
| Number | Date | Country | |
|---|---|---|---|
| 63552793 | Feb 2024 | US | |
| 63472561 | Jun 2023 | US | |
| 63472557 | Jun 2023 | US | |
| 63472562 | Jun 2023 | US |
