AI-enhanced host-specific python scripting system

Abstract

An AI-assisted host-specific Python script system includes a host system, a Python development system, and a generative AI (GAI) system communicatively coupled to the host system through a host system interface, the generative AI (GAI) system specifically trained to provide Python development information for generating a Python script in the Python development system to implement a host system function. The host system can include an enterprise asset management (EAM) system. The Python development information can include a Python script template. The GAI system can be trained using actual or simulated queries of the host system function. The Python script can be executed within the Python development system and can execute the host system function through an interface (e.g., a REST API) between the Python development system and the host system.

Description

[0001] Cross-reference to related applications

[0002] This patent application claims the benefit of U.S. Provisional Patent Application No. 63 / 626,690, filed January 30, 2024, entitled AI-ENHANCED HOST-SPECIFICPYTHON SCRIPTING SYSTEM, the entire contents of which are incorporated herein by reference. The subject matter of this patent application may also relate to the subject matter of U.S. Patent Application No. 18 / 141,455, entitled CLOUD-BASED SYSTEMS AND METHODSFOR EXECUTION OF PYTHON SCRIPTS, filed April 30, 2023, published October 31, 2024, and published as U.S. Patent Application Publication No. US 2024 / 0362071, the entire contents of which are incorporated herein by reference. Background Technology

[0003] Python is one of the most accessible programming languages ​​available because of its simplified and uncomplicated syntax, which provides a greater emphasis on natural language. Summary of the Invention

[0004] The AI-assisted host-specific Python scripting system includes a host system, a Python development system, and a generative AI (GAI) system communicatively connected to the host system via an interface. The GAI system is specifically trained to provide Python development information for generating Python scripts within the Python development system to implement host system functionalities. The GAI system may include chatbots. The host system may include an Enterprise Asset Management (EAM) system. The Python development information may include complete Python scripts and / or Python script templates. The GAI system can be trained or retrained using actual or simulated queries to the host system's functionalities. In this case, training and / or retraining may include human expert feedback (e.g., annotations on training data and simulated transactions) to allow the GAI system to benefit from expert input. The Python scripts can execute within the Python development system and can execute host system functionalities through an interface between the Python development system and the host system (e.g., a REST API).

[0005] Other embodiments may be disclosed and claimed. Attached Figure Description

[0006] Those skilled in the art will more fully appreciate the advantages of various embodiments of the invention from the “Description of Illustrative Embodiments” discussed below with reference to the accompanying drawings, which will be summarized immediately below.

[0007] Figure 1 This is a schematic diagram of an exemplary architecture for Python Studio according to certain embodiments.

[0008] Figure 2 This is a schematic diagram illustrating the Python Studio homepage according to certain embodiments.

[0009] Figure 3 This is a schematic diagram of the Python Studio page, which allows users to develop scripts section by section, thus facilitating script development.

[0010] Figure 4 An exemplary overview of system architectures that can be used to practice embodiments of this disclosure, based on some of the embodiments discussed herein, is provided.

[0011] Figure 5 Example cloud computing server computing entities are provided based on some embodiments discussed herein.

[0012] Figure 6 Example client computing entities are provided based on some embodiments discussed herein.

[0013] Figure 7 This is a schematic block diagram of a cloud computing server computing entity based on some embodiments discussed herein.

[0014] Figure 8 This is a schematic block diagram of a cloud computing server computing entity that operates a request management and container management engine across multiple availability zones, based on some embodiments discussed herein.

[0015] Figure 9 This is a schematic diagram illustrating details of a cloud-based multi-domain solver system 101 according to various embodiments.

[0016] Figure 10 It shows the basis Figure 9 A schematic diagram illustrating the details of an embodiment of the REST API.

[0017] Figure 11 This is a schematic diagram illustrating three primitives of a REST API according to certain embodiments.

[0018] Figure 12 The progress of a script execution transaction according to certain embodiments is illustrated schematically.

[0019] Figure 13 Additional details of the progress of a script execution transaction according to certain embodiments are illustrated schematically.

[0020] Figure 14 This is a schematic diagram of an AI-enhanced host-specific Python scripting system according to certain embodiments.

[0021] Figure 15 This is a logic flowchart of an AI-enhanced host-specific Python scripting system according to certain embodiments.

[0022] It should be noted that the foregoing figures and the elements described therein are not necessarily drawn to a uniform scale or any scale. Unless the context otherwise requires, the same elements are represented by the same numbers. The figures are for illustrative purposes only and are not intended to limit the scope of the subject matter of the invention described herein. Detailed Implementation

[0023] Various embodiments of this disclosure are described more fully below with reference to the accompanying drawings, which illustrate some, but not all, of these embodiments. In fact, this disclosure may be implemented in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements. Unless otherwise specified, the term “or” is used herein in a substitute and combined sense. The terms “illustrative” and “exemplary” are used as examples without indicating a level of quality. Throughout the text, the same reference numerals denote the same elements. As used herein, the terms “data entity” and “data structure” are used interchangeably.

[0024] I. General Overview and Technical Advantages

[0025] Various embodiments of this disclosure generally relate to a Python (PYN) development, management, and execution system architecture or framework, wherein Python script development and Python execution occur in a containerized, cloud-based (e.g., serverless) multi-tenant manner. Multi-tenancy enables software vendors to serve many customers with the same infrastructure in a highly scalable manner, resulting in lower costs and better resource utilization. Furthermore, multi-tenancy enables software vendors to release new features and updates faster, as they only need to deploy changes to a single application instance. For convenience, the script execution system may be referred to herein as Flex Python. Some embodiments additionally or alternatively include a Python script development system that allows users to write and publish Python scripts for execution. For convenience, the script development system may be referred to herein as Python Studio. As discussed further below, certain components of Flex Python and / or Python Studio can be integrated with host systems, such as Enterprise Asset Management (EAM) systems, such as the Infor / Hexagon Enterprise Asset Management (EAM) system from Intergraph / hexagon, Inc., and formerly from Infor (US) LLC; however, it should be noted that the embodiments can be configured to be more general in various systems. In some embodiments, the script may be user-initiated, event-triggered (e.g., configured via FlexSQL), and / or integrated with an alert module (e.g., EAM Alerts).

[0026] Specifically, in various embodiments, Flex Python is at least partially based on the execution of one or more container instances of one or more compute containers, each corresponding to a Python script. The container instances are executed in a serverless manner within a cloud-based, multi-domain system. That is, compute and processing resources can be recruited on demand and asynchronously for the execution of container instances. Therefore, various embodiments of this disclosure provide technical advantages by enabling flexible and elastic execution of Python scripts. In various example instances, compute and processing resources can be transferred, allocated, reserved, and / or used for specific scripts, and compute and processing resources can be conserved when the script's capacity is low. Therefore, the cloud-based and serverless execution of Python scripts in various embodiments of this disclosure results in efficient, flexible, and elastic use of compute and processing resources, which further translates into savings in time and real-world costs.

[0027] In various embodiments, the execution of a Python script is at least partially based on the execution of a container instance or the instantiation of a compute container. A compute container can be understood as a containerization or package of computer-executable instructions for a given script and may include additional data (e.g., libraries, dependency data) required or used by the script. Various embodiments of this disclosure relate to the use of compute containers for various scripts or sets of scripts, and the containerization of various scripts provides various technical advantages. In particular, the use of compute containers enables flexibility and scalability because multiple container instances of a compute container can be executed substantially in parallel without excessive consumption of computational and processing resources.

[0028] In various embodiments, users initiate the execution of a Python script via an application programming interface (API) (e.g., a RESTful API) without knowing the cloud environment in which the script is being executed. Cloud infrastructure typically has a minimal footprint when no script is running (e.g., zero state), and it preferably minimizes the cost of a zero-state footprint. Cloud-based architectures allow script execution instances to scale to, for example, tens of thousands of concurrent executions. Script execution instances are preferably stateless. In some embodiments, a script is constrained to complete within a specified amount of time (this can be fixed for all scripts or negotiated / specified on a script-by-script basis), otherwise the script is terminated. Embodiments typically also provide mechanisms to allow script termination via the API, and mechanisms to return script results upon completion or otherwise required.

[0029] In some embodiments, the system will execute multiple (e.g., two) instances of the Flex Python service (sometimes referred to herein as "solvers") in different availability zones. Preferably, the solver instances can be started on demand, thus not requiring persistent presence in the cloud. Once a solver instance has finished processing, it can be destroyed, thus incurring no cost when not in use.

[0030] II. Exemplary Definitions of Specific Terms

[0031] The term "computation container" can refer to and describe a data structure configured to describe an instantiable package, bundle, image, etc., of computer-executable instructions. According to various embodiments, a computation container includes computer-executable instructions for a specific Python script. That is, a computation container corresponding to a script can electronically embody and / or implement that script. A computation container may also include various libraries, dependency data, etc., required to embody and / or implement the script. A computation container can be instantiated as a container instance within a cloud-based multi-domain solver system, which consumes computation and processing resources independently on an on-demand basis. Various systems, methods, architectures, etc., such as Docker, can be used to define computation containers.

[0032] The term "container instance" can refer to and describe a data structure configured to describe the instantiation of a compute container, which involves the execution of computer-executable instructions defined by the compute container. Multiple container instances for a compute container can execute substantially in parallel; that is, a compute container can be instantiated more than once. Container instances can execute within a cloud-based multi-domain solver system, and thus utilize compute and processing resources on an on-demand basis. A cloud-based multi-domain solver system can include container instances corresponding to different compute containers that execute in parallel and / or substantially simultaneously. The count of container instances of compute containers can be scaled up and / or down, which also provides technical advantages in the improved management and use of compute and processing resources within a cloud-based multi-domain solver system.

[0033] The term "serverless container management engine" can refer to a data entity configured to manage the execution of container instances of compute containers, each corresponding to a Python script within a cloud-based multi-domain solver system. In doing so, the serverless container management engine can monitor the execution of container instances. Typically, the serverless container management engine is configured to scale (up or down) the count of container instances based at least in part on a variety of factors. For example, the serverless container management engine can reduce the count of currently and concurrently executing container instances within the cloud-based multi-domain solver system (e.g., by pausing and / or terminating some container instances) based at least in part on the availability of compute and processing resources within the cloud-based multi-domain solver system, current request demands (e.g., the count of scripts posted for execution), etc. Similarly, the serverless container management engine can increase the count of currently and concurrently executing container instances within the cloud-based multi-domain solver system for similar reasons. In various embodiments, the serverless container management engine is configured to spawn new container instances of compute containers, and in doing so, can be configured to access the data of the compute containers. Typically, serverless container management engines can be configured to allocate, assign, distribute, and / or similar compute and processing resources to various container instances. Example serverless container management engines that may be used according to various embodiments of this disclosure include, but are not limited to, Amazon Web Services (AWS) Fargate and Kubernetes.

[0034] The term "computing and processing resources" generally refers to and describes computing and processing components used to process and execute computer-executable instructions, such as one or more processors, memory, network interfaces, and / or portions thereof. For example, the processors, memory, and network interfaces of a cloud computing server computing entity can be computing and processing resources used to execute container instances. The use and utilization of computing and processing resources for various computer-executable instructions (e.g., container instances) can be measured, monitored, allocated, distributed, etc. In the example where the processor is a central processing unit (CPU), CPU time can be partitioned and distributed across different container instances. Similarly, resource utilization or use can include the amount of memory reserved or used by container instances, and monitoring such resource utilization or use can include locating potential memory leaks.

[0035] The term "serverless request management engine" can refer to and describe a data entity configured to manage the reception of script execution API requests and the transmission of script API responses within a cloud-based multi-domain solver system. A serverless request management engine can be serverless because the reception and processing of script execution API requests and the transmission of script API responses can consume a dynamic or variable amount of computational and processing resources. At a serverless request management engine, multiple API requests can be received simultaneously and / or over a period of time. In various embodiments, a cloud-based multi-domain solver system includes one or more serverless request management engines, each corresponding to an availability zone and configured to handle communication with a specific group of client computing entities, communication within a specific time period, communication with client computing entities located in a specific region, etc. The use of one or more serverless request management engines advantageously allows for the efficient handling of communication (e.g., receiving script execution API requests, sending script API responses) with minimal latency among a large number of client computing entities.

[0036] III. Computer program products, methods, and computing entities

[0037] Embodiments of this disclosure can be implemented in various ways, including as a computer program product including an article of manufacture. Such a computer program product may include one or more software components, including, for example, software objects, methods, data structures, etc. The software components can be encoded using any of a variety of programming languages. The descriptive programming language may be a lower-level programming language, such as assembly language associated with a specific hardware architecture and / or operating system platform. Software components including assembly language instructions may need to be converted into executable machine code by an assembler before execution by the hardware framework and / or platform. Another example programming language may be a higher-level programming language that is portable across multiple frameworks. Software components including high-level programming language instructions may need to be converted into an intermediate representation by an interpreter or compiler before execution.

[0038] Other examples of programming languages ​​include, but are not limited to, macro languages, shell or command languages, job control languages, scripting languages, database query or search languages, and / or report writing languages. In one or more embodiments, a software component including instructions from one of the foregoing examples of a programming language can be executed directly by an operating system or other software components without necessarily being first converted to another form. Software components can be stored as files or other data storage constructs. Software components of similar type or functionally related may be stored together, for example, in a specific directory, folder, or library. Software components can be static (e.g., pre-built or fixed) or dynamic (e.g., created or modified at runtime).

[0039] Computer program products may include non-transitory computer-readable storage media storing applications, programs, program modules, scripts, source code, program code, object code, bytecode, compiled code, interpreted code, machine code, executable instructions, etc. (also referred to herein as executable instructions, instructions for execution, computer program products, program code, and / or similar terms used interchangeably herein). Such non-transitory computer-readable storage media include all computer-readable media (including volatile and non-volatile media).

[0040] In one embodiment, a non-volatile computer-readable storage medium may include a floppy disk, a hard disk, a solid-state storage (SSS) (e.g., a solid-state drive (SSD), a solid-state card (SSC), a solid-state module (SSM), an enterprise flash drive, magnetic tape, or any other non-transitory magnetic medium, etc.). Non-volatile computer-readable storage media may also include punched cards, paper tape, optical marking sheets (or any other physical medium having a perforated pattern or other optically identifiable markings), optical disc read-only memory (CD-ROM), rewritable optical disc (CD-RW), digital versatile disc (DVD), Blu-ray disc (BD), any other non-transitory optical medium, etc. Such non-volatile computer-readable storage media may also include read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory (e.g., serial, NAND, NOR, and / or the like), multi-media memory card (MMC), secure digital (SD) memory card, smart media card, compressed flash (CF) card, memory stick, and / or the like. In addition, non-volatile computer-readable storage media may also include conductive bridged random access memory (CBRAM), phase change random access memory (PRAM), ferroelectric random access memory (FeRAM), non-volatile random access memory (NVRAM), magnetoresistive random access memory (MRAM), resistive random access memory (RRAM), silicon-oxide-nitride-oxide-silicon memory (SONOS), floating junction gate random access memory (FJG RAM), Millipede memory, racetrack memory, etc.

[0041] In one embodiment, a volatile computer-readable storage medium may include random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), fast page mode dynamic random access memory (FPM DRAM), extended data output dynamic random access memory (EDO DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), double data rate type 2 synchronous dynamic random access memory (DDR2 SDRAM), double data rate type 3 synchronous dynamic random access memory (DDR3 SDRAM), Rambus dynamic random access memory (RDRAM), dual transistor RAM (TTRAM), thyristor RAM (T-RAM), zero capacitor (Z-RAM), Rambus embedded memory module (RIMM), dual embedded memory module (DIMM), single embedded memory module (SIMM), video random access memory (VRAM), cache memory (including various levels), flash memory, register memory, etc. It should be understood that when embodiments are described as using computer-readable storage media, other types of computer-readable storage media may be used instead of those described above.

[0042] As should be understood, the various embodiments of this disclosure can also be implemented as methods, apparatus, systems, computing devices, computing entities, etc. Accordingly, embodiments of this disclosure can take the form of apparatus, systems, computing devices, computing entities, etc., that execute instructions stored on a computer-readable storage medium to perform certain steps or operations. Therefore, embodiments of this disclosure can also take the form of entirely hardware embodiments, entirely computer program product embodiments, and / or embodiments including a combination of computer program products and hardware that perform certain steps or operations.

[0043] Embodiments of the present disclosure are described below with reference to block diagrams and flowcharts. Therefore, it should be understood that each block in the block diagrams and flowcharts can be implemented as a computer program product, a complete hardware embodiment, a combination of hardware and computer program products, and / or as an apparatus, system, computing device, computing entity, etc., that executes interchangeable instructions, operations, steps, and similar terms (e.g., executable instructions, instructions for execution, program code, etc.) on a computer-readable storage medium for execution. For example, code retrieval, loading, and execution can be performed sequentially, such that one instruction is retrieved, loaded, and executed at a time. In some exemplary embodiments, retrieval, loading, and / or execution can be performed in parallel, such that multiple instructions are retrieved, loaded, and / or executed together. Therefore, such embodiments can produce machines that perform a particular configuration of steps or operations specified in the block diagrams and flowcharts. Thus, the block diagrams and flowcharts support various combinations of embodiments for performing the specified instructions, operations, or steps.

[0044] IV. Exemplary Python Studio Implementation

[0045] Figure 1 This is a schematic diagram of an exemplary architecture for Python Studio according to certain embodiments. The architecture includes a master Kubernetes node, PYN Studio Service worker nodes running PYN Studio Service instances, and multiple application worker nodes that are started as needed to run the PYN Studio user interface, through which users can develop and manage PYN scripts. The PYN Studio service receives PYN Studio API requests. In this example, the PYN Studio API request is initiated directly from the host system (e.g., directly from the HxGN EAM menu). The request is sent to a job queue via the Kubernetes API. The control plane creates a Pod containing the script container. In a zero-state condition (where no application worker node has been created), Kubernetes spins up a new worker node and assigns the Pod to it for execution. If an application worker node already exists and has capacity, the Kubernetes scheduler can assign the Pod to an available worker node. In this example, the script container is a container created from a container image that loads Python scripts to develop and manage applications. When complete, the Python script is saved or published to a documentation repository, from which the script can be managed and its execution scheduled.

[0046] Python script development applications present multiple user interface pages through which users can develop and manage scripts. Figure 2 This is a schematic diagram illustrating the Python Studio main page according to some embodiments. This page (or a similar page) is typically displayed when PYN Studio is launched. From this page, users can create new scripts or continue working on existing ones. Figure 3 This is a schematic diagram of the Python Studio page, which allows users to develop scripts section by section, thus facilitating script development.

[0047] The ability to launch Python Studio directly from the host application, and to execute scripts from the host system (e.g., user-initiated or automatically launched in an event-driven manner), significantly adds power and flexibility to the host system. Furthermore, Python Studio provides extensibility for writing, managing, and executing Python scripts, which can include anything from simple Python scripts to complex machine learning algorithms (e.g., TensorFlow), including the ability to include or run other scripts. Python Studio can leverage scripting tools available in the public domain or commercially (e.g., JupyterLab).

[0048] V. Exemplary Flex Python System Architecture

[0049] Figure 4 This is a schematic diagram of an exemplary architecture 100 for Flex Python according to certain embodiments. Architecture 100 includes a cloud-based multi-domain solver system 101 configured to receive script execution API requests, manage the execution of container instances corresponding to computational containers of scripts, and provide script output. In various embodiments, the cloud-based multi-domain solver system 101 scales the count of container instances undergoing execution based at least in part on various factors, including the availability of computational and processing resources and the number of script execution API requests received. For example, the cloud-based multi-domain solver system 101 may allocate, increase, distribute, etc., computational and processing resources to executing container instances, and / or may limit, reduce, cut off, etc., computational and processing resources of executing container instances.

[0050] In various embodiments, the cloud-based multi-domain solver system 101 communicates with multiple client computing entities 102 using one or more communication networks. Examples of communication networks include any wired or wireless communication network, including, for example, a wired or wireless local area network (LAN), a personal area network (PAN), a metropolitan area network (MAN), a wide area network (WAN), etc., and any hardware, software, and / or firmware (e.g., a network router, etc.) required to implement it. The cloud-based multi-domain solver system 101 can receive script execution API requests from various client computing entities 102 via such communication networks, and can also send script API responses to various client computing entities 102 via such communication networks.

[0051] Cloud-based multi-domain solver system 101 may include a cloud computing server computing entity 106 and a storage subsystem 108. The cloud computing server computing entity 106 may be configured to serverlessly execute container instances to determine solutions to input problems. That is, the execution of container instances can be achieved using a variable number of computing and processing resources of the cloud computing server computing entity 106. In this respect, the cloud computing server computing entity 106 can be understood as an abstraction of one or more separate computing entities sharing computing and processing resources. The cloud computing server computing entity 106 may be configured to receive and process script execution API requests. In various embodiments, the cloud computing server computing entity 106 generates and terminates container instances (e.g., by providing and / or removing computing and processing resources from the container instance), executes scripts, and provides script API responses.

[0052] Storage subsystem 108 can be configured to store data used by cloud computing server computing entity 106 in a containerized, cloud-based manner. For example, storage subsystem 108 can be configured to store computing containers, each corresponding to a script and configured to be instantiated and executed as a container instance. Storage subsystem 108 can also be configured to store inbound problem queues and outbound solution queues for scheduling and communication management as needed. Storage subsystem 108 may include one or more storage units, such as multiple distributed storage units connected via a computer network (e.g., the internal communication network of the cloud-based multi-domain solver system 101). Each storage unit in storage subsystem 108 can store at least one of one or more data assets and / or at least one or more data about the attributes of one or more data assets being computed. In addition, each storage unit in the storage subsystem 108 may include one or more non-volatile storage or storage media, including but not limited to hard disks, ROMs, PROMs, EPROMs, EEPROMs, flash memory, MMC, SD memory cards, memory sticks, CBRAMs, PRAMs, ferams, NVRAMs, MRAMs, RRAMs, SONOS, FJGRAMs, Millipede memory, track memory and / or the like.

[0053] Exemplary cloud computing server computing entity

[0054] Figure 5 A schematic diagram of a cloud computing server computing entity 106 according to one embodiment of this disclosure is provided. Generally, the terms computing entity, computer, entity, device, system, and / or similar terms used interchangeably herein can refer to, for example, one or more computers, computing entities, desktop computers, mobile phones, tablet computers, large-screen phones, laptop computers, distributed systems, self-service machines, input terminals, servers or server networks, blades, gateways, switches, processing devices, processing entities, set-top boxes, repeaters, routers, network access points, base stations, etc., and / or any combination of devices or entities suitable for performing the functions, operations, and / or processes described herein. Such functions, operations, and / or processes may include, for example, sending, receiving, operating, processing, displaying, storing, determining, creating / generating, monitoring, evaluating, comparing, and / or similar terms used interchangeably herein. In one embodiment, these functions, operations, and / or processes may be performed on data, content, information, and / or similar terms used interchangeably herein.

[0055] As indicated, in one embodiment, the cloud computing server computing entity 106 may also include one or more communication interfaces 220 for communicating with various computing entities, such as through communication data, content, information, and / or similar terms that can be sent, received, manipulated, processed, displayed, stored, etc., interchangeably used herein. The cloud computing server computing entity 106 may communicate with multiple client computing entities 102 via one or more communication interfaces 220, such as receiving script execution API requests and sending script API responses.

[0056] like Figure 5 As shown, in one embodiment, the cloud computing server computing entity 106 may include, for example, one or more processing elements 205 (also referred to as processors, processing circuitry, and / or similar terms used interchangeably herein) that communicate with, or to, other elements within the cloud computing server computing entity 106, for example via a bus. As will be understood, the processing elements 205 may be implemented in many different ways.

[0057] For example, processing element 205 may be implemented as one or more complex programmable logic devices (CPLDs), microprocessors, multi-core processors, coprocessor entities, application-specific instruction set processors (ASIPs), microcontrollers, and / or controllers. Furthermore, processing element 205 may be implemented as one or more other processing devices or circuits. The term "circuit" can refer to a completely hardware embodiment or a combination of hardware and computer program products. Therefore, processing element 205 may be implemented as an integrated circuit, application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), programmable logic array (PLA), hardware accelerator, other circuits, and / or the like.

[0058] Therefore, it can be understood that processing element 205 can be configured for a particular purpose, or configured to execute instructions stored in volatile or non-volatile media or instructions accessible to processing element 205. Accordingly, whether configured by hardware, computer program products, or a combination thereof, processing element 205 is capable of performing steps or operations according to embodiments of the present disclosure when configured accordingly.

[0059] In one embodiment, the cloud computing server computing entity 106 may also include or communicate with a non-volatile medium (also referred to as a non-volatile storage device, memory, memory storage device, memory circuit, and / or similar terms used interchangeably herein). In one embodiment, the non-volatile storage device or memory may include one or more non-volatile memories or storage media 210, including but not limited to hard disks, ROMs, PROMs, EPROMs, EEPROMs, flash memory, MMC, SD memory cards, Memory Sticks, CBRAMs, PRAMs, ferams, NVRAMs, MRAMs, RRAMs, SONOS, FJGRAMs, Millipede memory, track memory, etc.

[0060] As will be recognized, non-volatile storage devices or storage media can store databases, database instances, database management systems, data, applications, programs, program modules, scripts, source code, object code, bytecode, compiled code, interpreted code, machine code, executable instructions, etc. The terms database, database instance, database management system, and / or similar terms, used interchangeably herein, can refer to a collection of records or data stored in a computer-readable storage medium using one or more database models, such as hierarchical database models, network models, relational models, entity-relationship models, object models, document models, semantic models, graph models, etc.

[0061] In one embodiment, the cloud computing server computing entity 106 may also include or communicate with volatile media (also referred to as volatile storage devices, memory, memory devices, memory circuits, and / or similar terms used interchangeably herein). In one embodiment, the volatile storage device or memory may further include one or more volatile memories or storage media 215, including but not limited to RAM, DRAM, SRAM, FPMDRAM, EDODRAM, SDRAM, DDRSDRAM, DDR2SDRAM, DDR3SDRAM, RDRAM, TTRAM, T-RAM, Z-RAM, RIMM, DIMM, SIMM, VRAM, cache memory, register memory, etc.

[0062] As will be appreciated, volatile storage devices or storage media can be used to store at least a portion of databases, database instances, database management systems, data, applications, programs, program modules, scripts, source code, object code, bytecode, compiled code, interpreted code, machine code, executable instructions, etc., executed by, for example, processing element 205. Therefore, databases, database instances, database management systems, data, applications, programs, program modules, scripts, source code, object code, bytecode, compiled code, interpreted code, machine code, executable instructions, etc., can be used to control certain aspects of the operation of the cloud computing server computing entity 106 with the help of processing element 205 and the operating system.

[0063] As indicated, in one embodiment, the cloud computing server computing entity 106 may also include one or more communication interfaces 220 for communicating with various computing entities, such as communicating data, content, information, and / or similar terms interchangeably used herein that can be sent, received, manipulated, processed, displayed, stored, etc. Such communication may be performed using wired data transmission protocols, such as Fiber Distributed Data Interface (FDDI), Digital Subscriber Line (DSL), Ethernet, Asynchronous Transfer Mode (ATM), Frame Relay, Cable Data Service Interface Specification (DOCSIS), or any other wired transmission protocol. Similarly, the cloud computing server computing entity 106 can be configured to communicate via a wireless external communication network using any of a variety of protocols, such as General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), Code Division Multiple Access 2000 (CDMA2000), CDMA2000 1X (1xRTT), Wideband Code Division Multiple Access (WCDMA), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), Time Division Synchronous Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), Evolved Universal Terrestrial Radio Access Network (E-UTRAN), Evolved Data Optimized (EVDO), High Speed ​​Packet Access (HSPA), High Speed ​​Downlink Packet Access (HSDPA), IEEE 802.11 (Wi-Fi), Wi-Fi Direct, 802.16 (WiMAX), Ultra Wideband (UWB), Infrared (IR) protocol, Near Field Communication (NFC) protocol, Wibree, Bluetooth protocol, Wireless Universal Serial Bus (USB) protocol, and / or any other wireless protocol.

[0064] Although not shown, the cloud computing server computing entity 106 may include or communicate with one or more input elements, such as keyboard input, mouse input, touchscreen / display input, motion input, mobile input, audio input, pointing device input, joystick input, keypad input, etc. The cloud computing server computing entity 106 may also include or communicate with one or more output elements (not shown), such as audio output, video output, page / display output, motion output, mobile output, etc.

[0065] Exemplary client computing entity

[0066] Figure 6 An illustrative schematic diagram of a client computing entity 102 is provided for use in conjunction with embodiments of this disclosure. Generally, the terms device, system, computing entity, entity, and / or similar terms, used interchangeably herein, can refer to, for example, one or more computers, computing entities, desktop computers, mobile phones, tablet computers, large-screen phones, laptops, distributed systems, self-service machines, input terminals, servers or server networks, blades, gateways, switches, processing devices, processing entities, set-top boxes, repeaters, routers, network access points, base stations, etc., and / or any combination of devices or entities suitable for performing the functions, operations, and / or processes described herein. Client computing entity 102 may be operated by various parties. Figure 3 As shown, the client computing entity 102 may include an antenna 312, a transmitter 304 (e.g., a wireless device), a receiver 306 (e.g., a wireless device), and a processing element 308 (e.g., a CPLD, a microprocessor, a multi-core processor, a coprocessor entity, an ASIP, a microcontroller, and / or a controller) that provides signals to and receives signals from the transmitter 304 and the receiver 306 respectively.

[0067] Accordingly, the signals provided to and received from transmitter 304 and receiver 306 may include signaling information / data according to the air interface standard of the applicable wireless system. In this respect, client computing entity 102 can operate using one or more air interface standards, communication protocols, modulation types, and access types. More specifically, client computing entity 102 can operate according to any of a variety of wireless communication standards and protocols, such as those described above with respect to cloud computing server computing entity 106. In certain embodiments, client computing entity 102 can operate according to a variety of wireless communication standards and protocols, such as UMTS, CDMA2000, 1xRTT, WCDMA, GSM, EDGE, TD-SCDMA, LTE, E-UTRAN, EVDO, HSPA, HSDPA, Wi-Fi, Wi-Fi Direct, WiMAX, UWB, IR, NFC, Bluetooth, USB, etc. Similarly, client computing entity 102 can operate via network interface 320 according to a number of wired communication standards and protocols (such as those described above with respect to cloud computing server computing entity 106).

[0068] Through these communication standards and protocols, client computing entity 102 can use concepts such as Unstructured Supplemental Service Data (USSD), Short Message Service (SMS), Multimedia Messaging Service (MMS), Dual-Tone Multi-Frequency Signaling (DTMF), and / or Subscriber Identity Module Dialer (SIM Dialer) to communicate with a variety of other entities. Client computing entity 102 can also download changes, additions, and updates to, for example, its firmware, software (e.g., including executable instructions, applications, program modules), and operating system.

[0069] According to one embodiment, client computing entity 102 may include location determination aspects, devices, modules, functions, and / or similar terms used interchangeably herein. For example, client computing entity 102 may include outdoor positioning aspects, such as location modules adapted to acquire (e.g.) latitude, longitude, altitude, geocode, heading, direction, speed, UTC, date, and / or various other information / data. In one embodiment, the positioning module may acquire data, sometimes referred to as ephemeris data, by identifying the number of visible satellites and the relative positions of these satellites (e.g., using a Global Positioning System (GPS)). Satellites can be a variety of different satellites, including Low Earth Orbit (LEO) satellite systems, Department of Defense (DOD) satellite systems, the European Union Galileo positioning system, the Chinese Compass Navigation System, the Indian Regional Navigation Satellite System, etc. This data can be collected using multiple coordinate systems, such as decimal (DD); degrees, minutes, seconds (DMS); Universal Transverse Mercator (UTM); Universal Polar Solid (UPS) coordinate system, and / or the like. Alternatively, location information / data can be determined by triangulation client computing entity 102 in relation to various other systems, including cellular towers, Wi-Fi access points, and / or similar systems. Similarly, client computing entity 102 may include indoor positioning aspects, such as location modules adapted to acquire, for example, latitude, longitude, altitude, geocode, heading, direction, speed, time, date, and / or various other information / data. Some indoor systems may use various positioning or location technologies, including RFID tags, indoor beacons or transmitters, Wi-Fi access points, cellular towers, nearby computing devices (e.g., smartphones, laptops), and / or similar technologies. For example, such technologies may include iBeacons, Gimbal proximity beacons, Bluetooth Low Energy (BLE) transmitters, NFC transmitters, and / or the like. These indoor positioning aspects can be used in various setups to determine the location of a person or object within inches or centimeters.

[0070] The client computing entity 102 may also include a user interface (which may include a display 316 coupled to the processing element 308) and / or a user input interface (coupled to the processing element 308). For example, the user interface may be a user application, a browser, a user interface, and / or similar terms used interchangeably herein, which execute on and / or are accessible via the client computing entity 102 to interact with the cloud computing server computing entity 106 and / or cause the display of information / data from the cloud computing server computing entity 106, as described herein. The user input interface may include any of a number of devices or interfaces that allow the client computing entity 102 to receive data, such as a keypad 318 (hard or soft), a touch display, a voice / voice or motion interface, or other input devices. In embodiments including a keypad 318, the keypad 318 may include (or cause the display of) conventional numeric keys (0 to 9) and related keys (#, ... The user input interface includes, for example, keys for operating client computing entity 102, and may include a full set of alphabetic keys or a set of keys that can be activated to provide a full set of alphanumeric keys. In addition to providing input, the user input interface can also be used to activate or deactivate certain functions, such as screen saver and / or sleep mode.

[0071] The client computing entity 102 may also include embeddable and / or removable volatile storage devices or memories 322 and / or non-volatile storage devices or memories 324. For example, non-volatile memory may be ROM, PROM, EPROM, EEPROM, flash memory, MMC, SD memory card, Memory Stick, CBRAM, PRAM, FeRAM, NVRAM, MRAM, RRAM, SONOS, FJGRAM, Millipede memory, track memory, etc. Volatile memory may be RAM, DRAM, SRAM, FPMDRAM, EDODRAM, SDRAM, DDR SDRAM, DDR2 SDRAM, DDR3 SDRAM, RDRAM, TTRAM, T-RAM, Z-RAM, RIMM, DIMM, SIMM, VRAM, cache memory, register memory, etc. Volatile and non-volatile storage devices or memories can store databases, database instances, database management systems, data, applications, programs, program modules, scripts, source code, object code, bytecode, compiled code, interpreted code, machine code, executable instructions, etc., to implement the functionality of client computing entity 102. As indicated, this may include user applications residing on the entity or accessible through a browser or other user interface for communicating with cloud computing server computing entity 106 and / or various other computing entities.

[0072] In another embodiment, client computing entity 102 may include one or more components or functions that are the same as or similar to those of cloud computing server computing entity 106, as described in more detail above. As will be appreciated, these architectures and descriptions are provided for illustrative purposes only and are not limited to the various embodiments.

[0073] In various embodiments, the client computing entity 102 may be implemented as an artificial intelligence (AI) computing entity, such as Amazon Echo, Amazon Echo Dot, Amazon Show, Google Home, etc. Therefore, the client computing entity 102 may be configured to provide and / or receive information / data from a user via input / output mechanisms such as a display, camera, speaker, voice-activated input, etc. In some embodiments, the AI ​​computing entity may include one or more predefined and executable program algorithms stored in an onboard memory storage module and / or accessible via a network. In various embodiments, the AI ​​computing entity may be configured to retrieve and / or execute one or more predetermined program algorithms upon the occurrence of a predetermined triggering event.

[0074] VI. Exemplary Flex Python System Operation

[0075] In various embodiments, the cloud-based multi-domain solver system 101 includes a request management engine that communicates with and / or includes a type-agnostic problem API. Figure 7 An example block diagram of a cloud computing server computing entity 106, including a request management engine 502, is shown. The request management engine 502 is configured to receive, process, dispose of, and / or handle script execution API requests originating from various client computing entities 102.

[0076] In various embodiments, the cloud computing server computing entity 106 includes one or more request management engines 502, each request engine 502 being configured to receive and process requests originating from sources such as... Figure 8The various client computing entities 102 shown represent script execution API requests. In such an embodiment, each request management engine 502 may correspond to availability zones 510A-B. Availability zones 510A-B describe the scope of responsibility of the respective request management engine 502. For example, a first request management engine 502A corresponding to a first availability zone 510A may be configured to receive and process script execution API requests originating from a first group of client computing entities 102, while a second request management engine 502B corresponding to a second availability zone 510B may be configured to receive and process script execution API requests originating from a second group of client computing entities 102. As another example, the use of request management engines 502 in different availability zones 510A-B may be at least partially based on demand, wherein the second request management engine 502B corresponding to the second availability zone 510B is configured to receive and process script execution API requests when the first request management engine 502A corresponding to the first availability zone 510A consumes a threshold amount of computing and processing resources while receiving and processing script execution API requests. Therefore, using more than one request management engine 502 and dividing the same request management engine 502 among different availability zones 510A-B advantageously provides efficient and flexible use of computing and processing resources.

[0077] In various embodiments, the request management engine 502 can communicate with the inbound issue queue 506. In various instances, the request management engine 502 can receive multiple script execution API requests. In various embodiments, the script execution requests can be organized within the inbound issue queue 506, such as in a first-in, first-out (FIFO) manner.

[0078] Computational containers are instantiated as container instances within the cloud-based multi-domain solver system 101. These container instances consume computational and processing resources independently on an on-demand basis. That is, a container instance is defined as an instantiation of a computational container. When a container instance is created, it can be configured to begin execution automatically and independently. The execution of a container instance consumes a certain amount of computational and processing resources, and such resources can be appropriately allocated and distributed among one or more container instances. In various embodiments, the minimum amount of computational and processing resources required to execute a container instance of a particular computational container can be a parameter defined and described for that particular computational container, and a container instance can be created when at least the minimum amount of computational and processing resources required for execution is available.

[0079] The creation and execution of container instances can be managed by one or more container management engines 504 of the cloud computing server computing entity 106, such as... Figure 7 and Figure 8As shown. In various embodiments, the container management engine 504 is configured to generate container instances of compute containers and dynamically allocate the amount of compute and processing resources to execute the container instances. As part of the dynamic allocation of compute and processing resources among one or more container instances, the container management engine 504 is configured to monitor the use and allocation of compute and processing resources of the cloud computing server compute entity 106 and reallocate such resources among container instances as deemed necessary. Similarly, the container management engine 504 is configured to monitor the amount of available compute and processing resources and generate a container instance if the amount of available compute and processing resources meets the minimum amount of compute and processing resources required for the execution of the container instance. In various embodiments, the container management engine 504 does not allocate excessive compute and processing resources to the container instances, and the amount of compute and processing resources allocated to the container instances may be limited by one or more configurable thresholds or limits. Various further variations of container instantiation will be apparent to those skilled in the art to which this disclosure pertains. For example, container instances for one or more compute containers are dynamically generated over time.

[0080] like Figure 8 As shown, the cloud computing server computing entity 106 may include one or more container management engines 504, each container management engine corresponding to an availability zone 510, and each container management engine is configured to manage the generation and execution of container instances for script requests received in its corresponding availability zone 510. Furthermore, the computing and processing resources of the cloud computing server computing entity 106 may be partitioned or allocated among multiple availability zones 510, and the container management engines 504 are configured to allocate computing and processing resources for their respective availability zones 510 to the generation and execution of container instances. In the illustrated embodiment, the cloud computing server computing entity 106 includes a first container management engine 504A corresponding to a first availability zone 510A and a second container management engine 504B corresponding to a second availability zone 510B.

[0081] One or more container instances can be generated (e.g., via container management engine 504), at least in part, based on inbound issue queue 506. Specifically, inbound issue queue 506 can instruct a particular script to be ready for execution and can communicate with container management engine 504 to generate container instances for one or more compute containers, each corresponding to a selected script. While communicating with inbound issue queue 506, container management engine 504 can receive or retrieve scripts including various parameters, values, and data related to the input issue and can provide the scripts to the container instances during generation. Therefore, once generated, the container instances are equipped to execute the scripts.

[0082] As previously described, container instances can be configured to automatically begin execution upon spawning. In various embodiments, the container instance may include a heartbeat API to indicate that a script is currently being executed using the container instance (e.g., the container instance is "active"). In various embodiments, the container instance communicates via the heartbeat API with the container management engine 504 and / or the inbound issue queue 506, notifying the container management engine 504 and / or the inbound issue queue 506 that the container instance is "alive" and is executing. During the execution of at least one container instance for a specific input issue, the state associated with a particular script at the inbound issue queue 506 can be configured as "processing," "disposal," and / or a similar state.

[0083] In various embodiments, monitoring the execution of a container instance includes monitoring the amount of computing and processing resources allocated to and / or consumed by the container instance. When monitoring the resource usage and utilization of a container instance, usage data associated with multiple points in time can be collected and analyzed. In various embodiments, usage data includes dedicated processing time (e.g., a portion of the total time spent processing the container instance by one or more processors), memory size (e.g., the amount of volatile and / or non-volatile memory reserved and used by the container instance), etc.

[0084] In some embodiments, the execution of a container instance can be paused via the container instance's heartbeat API. For example, a container instance may receive stop, cancel, terminate, and / or similar commands from container management engine 504 via the heartbeat API. In some embodiments, a container instance is configured to automatically pause execution in response to one or more unsatisfactory per-iteration optimization gains and may send a final heartbeat message indicating the pause via the heartbeat API. In various embodiments, container instances and / or similar operations can be stopped, paused, killed, or terminated by limiting or stopping the allocation of compute and processing resources to the container instance. Compute and processing resources may be actively deallocated from the container instance (e.g., by container management engine 504) to other container instances. Additionally or alternatively, the pause of a container instance's execution may be based on a timeout value associated with a script, for example, if the script does not complete within a specified timeout value.

[0085] The script output can include updating outbound solution queue 508, such as... Figure 7 and Figure 8As shown. Since multiple input questions can be received within a time period, outbound solution queue 508 can be configured to identify (e.g., store) more than one script output. Outbound solution queue 508 can also store the status associated with each script output, and script outputs with "ready to return," "ready to send," and / or similar statuses can be added to outbound solution queue 508. Adding script outputs to outbound solution queue 508 can also include updating inbound question queue 506. For example, a script in inbound question queue 506 can be updated to a "completed" status and / or removed from inbound question queue 506.

[0086] The generation of script output may also include scaling down container instances. When script output is generated, execution of the container instance is no longer required, and such container instances can be paused, suspended, and / or terminated. In some embodiments, some container instances may be redirected to other scripts identified by inbound issue queue 506, and script characteristics may be received and / or retrieved accordingly from inbound issue queue 506. However, in some instances, another script may be unavailable, and the container instance may be terminated. Therefore, the count of executing container instances is flexible and is at least in part based on the number of scripts in inbound issue queue 506.

[0087] In various embodiments, script output can be provided to client computing entity 102 via request management engine 502. Script output can be specifically provided via request management engine 502 corresponding to availability zones 510A-B, where script execution API requests are received. When providing script output, request management engine 502 can be configured to communicate with outbound solution queue 508 (e.g., to receive or retrieve script output from at least outbound solution queue 508). After providing script output, outbound solution queue 508 can be updated, and specifically, script output can be deleted from outbound solution queue 508.

[0088] Therefore, various steps, operations, methods, processes, etc., for executing Python scripts in a containerized, cloud-based (e.g., serverless) manner are described herein. In an example embodiment, a script execution API request is received from client computing entity 102. The script execution API request is processed, and the corresponding input is added to inbound issue queue 506 (e.g., by request management engine 502). The script is notified to container management engine 504 via inbound issue queue 506, and container management engine 504 generates one or more container instances, each associated with a script (e.g., by request management engine 502). Execution of one or more container instances results in the generation of one or more script outputs. The script outputs are added to outbound solution queue 508, while the input script is removed from inbound issue queue 506. The script outputs are then provided to client computing entity 102 via script API response (e.g., via request management engine 502).

[0089] The various embodiments described herein offer a variety of technical advantages through optimized solutions that enable flexible and resilient determination of the amount of scripts to be executed. In various example instances, computing and processing resources can be transferred, allocated, reserved, and / or similarly, and can be conserved when the amount of scripts is low. Therefore, cloud-based and serverless script execution in the various embodiments of this disclosure results in efficient, flexible, and resilient use of computing and processing resources, which further translates into savings in time and real-world costs. Furthermore, the use of various script computing containers enables flexibility and scalability, as multiple container instances of computing containers can be executed substantially in parallel without excessive consumption of computing and processing resources.

[0090] VII. Exemplary Flex Python Implementation

[0091] Figure 9 This is a schematic diagram illustrating details of a cloud-based multi-domain solver system 101 according to various embodiments. The cloud-based multi-domain solver system 101 includes a provisioning API, a master Kubernetes node, at least one (and preferably two or more) PYN service worker nodes each running a PYN service instance, and multiple application worker nodes that are started as needed to run Python scripts.

[0092] The supply API verifies the system's clients. Specifically, when the system receives a specific client ID for the first time, the client ID is verified via the supply API and persistently stored in the database. Then, each time a solution request transaction is received from that client, the system can confirm that the client is valid and can use the solver service.

[0093] The PYN service receives script execution API requests from individual users via a multi-domain representative state transfer (REST) ​​API. This REST API is preferably configured to allow multiple different domain-specific client computing entities to be added to and removed from the system in a plug-and-play manner, for example, added as support for a new domain. Users can include external and / or internal users (e.g., host systems such as EAM systems or other entities). Requests are validated and then sent to a job queue via the Kubernetes API. The control plane creates a Pod containing the application container. In zero-state (where no application worker node has been created), Kubernetes spins up a new worker node and assigns the Pod to it for execution. If the application worker node already exists and has capacity, the Kubernetes scheduler can assign the Pod to an available worker node. The application is a container created from a container image that loads the user's Python zip for execution. The Python zip contains a .py file listing any dependent packages and a requirements.txt file. Python executable scripts can be accessed, for example, from AWS S3, Azure Blob, or the EAM Document Repository. The Python script executes in isolation from other Pods. When the Python script completes, any output is sent to the response controller of the PYN service worker node, which then sends an asynchronous acknowledgment to the calling application. In some embodiments, Kubernetes nodes running on EC2 instances are protected by Crowdstrike Falcon through a unified set of cloud delivery technologies that prevent breaches against all types of attacks, including malware.

[0094] Figure 10 It shows the basis Figure 9 This is a schematic diagram illustrating the details of the REST API in an embodiment. Different domain-specific client computational entities can utilize different parameters, and the REST API allows such domain-specific client computational entities to utilize this public API by sending domain-specific information to the PYN solver when making requests in a stateless manner (e.g., using JSON or other suitable representation formats). The REST API provides an extensible API that allows new functionality to be added without breaking backward compatibility. It uses JSON, a lightweight data exchange format that is easy for humans to read and write, and easy for machines to parse and generate. The API is based on the Open API specification. The REST API is associated with different specifications and attributes for different domains, which allows clients to use only the API for the domain they need and allows the solver system to send responses with domain-specific information to the client.

[0095] like Figure 11 As illustrated schematically, the REST API includes three primitives: the POST / services / solve primitive for initiating script execution, the GET / services / status / {id} primitive for requesting the execution status of the identified script, and the POST / services / cancel / {id} primitive for terminating the execution of the identified script. In some exemplary embodiments, the POST / services / solve primitive must specify the CPU size, memory size, and timeout value. In some embodiments, the POST / services / solve primitive specifies the number of virtual CPU units required for the request, the amount of memory required for the request, a timeout value indicating the maximum amount of time the Python script can run, a file access method (e.g., URL, host system API, etc.) indicating the method for retrieving the Python script, information about where / how to access the Python script (e.g., URL, filename, etc.) as appropriate, and user-provided parameters as appropriate. The Python script can be retrieved by the master node, by the Python service instance handling the request, or by the worker node executing the Python script.

[0096] Figure 12 and Figure 13 The diagram schematically illustrates the progress of a script execution transaction according to certain embodiments. A client (e.g., a plugin) sends a solution request to Flex Python via a REST API. The REST API authenticates the client and, assuming the client is authenticated, validates the request and pushes it to the master node. The script is executed as described above. Throughout the process, the master node updates status information, e.g., to indicate when the solver has processed the request and when the solver has completed the request. The response service pulls a solution from the outbound queue and sends it to the client via a callback API.

[0097] As described above, script execution can be initiated in various ways, such as user-initiated, event-triggered (e.g., through flexible configuration), and / or integrated with an alerting module (e.g., EAM alerts). Therefore, for example, in some embodiments, the host system can be configured to initiate the execution of one or more scripts based on events or alerts within the system. Without limitations, events can be based on time (e.g., executing script A every 15 minutes), internal events within the host system (e.g., initiating script execution whenever someone attempts to log in as a specific user), external events (e.g., monitoring online sources and initiating script execution based on those online sources), etc.

[0098] VIII. Includes AI-assisted system extensions

[0099] Considering the above description of Flex Python and Python Studio, it should be recognized that users can generally be represented by at least two “personas”, namely (1) users who are proficient in Python but do not have host systems such as EAM, and (2) users who are proficient in host systems but do not have Python.

[0100] For users who are proficient in Python but not in host systems, some implementations provide templates / scripts in Python Studio that provide access to features of the host system (e.g., EAM), such as how to integrate job order processing into EAM using the REST API.

[0101] For users proficient in host systems but not in Python, some embodiments add host system interfaces to generative AI (GAI) systems (e.g., ChatGPT) to allow users to use Python to augment or implement functionality within the host system. Since GAI systems typically do not inherently "understand" the host system (e.g., operations and protocols including Python integration), some embodiments additionally train GAI models (e.g., the ChatGPT chatbot) to understand the host system, for example, "How to Train ChatGPT On Your Data: A Guide to Building a Custom AI Chatbot" published November 8, 2023 at https: / / simplified.com / blog / ai-writing / how-to-train-chatgpt, and "How to build your own custom ChatGPT with OpenAI's GPT builder" by Lau, J., published November 14, 2023 at https: / / zapier.com / blog / custom-chatgpt / , each incorporated herein by reference in its entirety. For example, creating and training a chatbot may include preparing training data, installing Python including the Pip package manager and basic libraries (such as the OpenAI library, GPT index / LlamaIndex library, PyPDF2 library, PyCryptodome library, Grado library, etc.), installing a code editor (such as Notepad++, VS Code, Sublime Text, etc.), generating API keys and secret keys, selecting a model (such as gpt-3.5-turbo or gpt-4), creating a knowledge base including the training data, creating a Python script to train the chatbot using the training data, and running the script, etc. After the chatbot is trained, it can be deployed for use via a host system interface. For example, the GAI system can be integrated with a Python development system or a host system, or it can be implemented separately from both. Of course, the chatbot can be retrained from time to time, for example, based on real or simulated transactions. Training and / or retraining may include human intervention, such as annotating the training data and simulated transactions, to allow the GAI system to benefit from expert input. Therefore, for example, a user can input natural language prompts into a trained GAI system via the host system interface to obtain information on how to use Python to implement scripts for performing various operations on the host system.A trained GAI system can provide complete Python scripts or Python script templates that can be executed within the host system and / or within Python Studio.

[0102] Figure 14 This is a schematic diagram of an AI-enhanced host-specific Python scripting system according to certain embodiments. As described above, a host system (e.g., EAM) is enhanced using an interface of a GAI system trained with host-specific knowledge specifically designed to allow users to generate Python scripts to perform host system functions. Thus, for example, in response to a query, the trained GAI system can return Python script templates or other instructions to help the user generate Python scripts to perform specific host system functions. In the context described herein, the user can then utilize Python Studio or other suitable Python tools to generate Python scripts, which can then be executed, for example, by Python Studio or the host system itself, to perform the specific host system functions.

[0103] For example, Python Studio users can input natural language prompts into the trained GAI, such as "How do I use Python to interface with EAM to get a work order" or "How do I use Python to index arrays in EAM", and the GAI will respond with information to generate an appropriate Python script (e.g., a Python script template or a complete Python script).

[0104] Figure 15This is a logical flowchart of an AI-enhanced host-specific Python scripting system according to certain embodiments. Here, a host system, a Python development system, and a generative AI (GAI) system are provided, wherein the GAI system is communicatively connected to the host system via a host system interface. The GAI system is specifically trained to provide Python development information for generating Python scripts within the Python development system to implement host system functionalities. When the GAI system receives a natural language user query related to a Python script for a given host system function (e.g., via the host system interface), the GAI system returns Python development information related to the given host system function. The GAI system may include a chatbot. The host system may be an Enterprise Asset Management (EAM) system. The Python development information returned by the GAI system may include complete Python scripts and / or Python script templates. The GAI system can be trained and / or retrained using actual or simulated queries to host system functionalities, and training and / or retraining may include human expert feedback to allow the GAI system to benefit from expert input. The Python scripts can execute within the Python development system to perform host system functionalities through an interface between the Python development system and the host system (e.g., via a REST API).

[0105] IX. Conclusion

[0106] Many modifications and other embodiments will arise in those skilled in the art upon which this disclosure pertains, taking advantage of the teachings presented in the foregoing description and the accompanying drawings. Therefore, it should be understood that this disclosure is not limited to the specific embodiments disclosed, and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terminology is used herein, it is used only in a general and descriptive sense and not for limiting purposes.

Claims

1. An AI-assisted host-specific Python scripting system, the AI-assisted host-specific Python scripting system comprising: Host system; Python development system; as well as A generative AI (GAI) system communicatively connected to a host system via a host system interface, wherein the GAI system is specifically trained to provide Python development information for generating Python scripts in the Python development system to implement host system functions, and wherein the GAI system is configured to receive natural language user queries related to Python scripts for a given host system function and return Python development information related to the given host system function.

2. The system according to claim 1, wherein, The GAI system includes chatbots.

3. The system according to claim 1, wherein, The host system is an Enterprise Asset Management (EAM) system.

4. The system according to claim 1, wherein, The Python development information includes at least one of a complete Python script or a Python script template.

5. The system according to claim 1, wherein, The GAI system is trained and / or retrained using actual or simulated queries of the host system's functionality. Optionally, the training and / or retraining includes human expert feedback to allow the GAI system to benefit from expert input.

6. The system according to claim 1, wherein, The Python script is executed within the Python development system and performs host system functions through the interface between the Python development system and the host system. Optionally, the Python development system and the host system are connected communicatively via a representative state transition (REST) ​​API.

7. The system according to claim 1, wherein, The GAI system receives natural language user queries via the host system interface.

8. An AI-assisted host-specific Python scripting method, wherein the AI-assisted host-specific Python scripting method includes: Provide host system; Provides a Python development system; as well as A generative AI (GAI) system is provided, wherein the generative AI (GAI) system is communicatively connected to the host system via a host system interface; The GAI system is specially trained to provide Python development information for generating Python scripts in the Python development system, thereby realizing the functions of the host system; The GAI system receives natural language user queries related to Python scripts used for the functions of a given host system. as well as The GAI system returns Python development information related to the functionality of the given host system.

9. The method according to claim 8, wherein, The GAI system includes chatbots.

10. The method according to claim 8, wherein, The host system is an Enterprise Asset Management (EAM) system.

11. The method according to claim 8, wherein, The Python development information includes at least one of a complete Python script or a Python script template.

12. The method according to claim 8, wherein, The GAI system is trained and / or retrained using actual or simulated queries of the host system's functionality. Optionally, the training and / or retraining includes human expert feedback to allow the GAI system to benefit from expert input.

13. The method according to claim 8, wherein, The Python script is executed within the Python development system and performs host system functions through the interface between the Python development system and the host system. Optionally, the Python development system and the host system are connected communicatively via a representative state transition (REST) ​​API.

14. The method according to claim 8, wherein, The GAI system receives natural language user queries via the host system interface.

15. A computer program product comprising at least one tangible, non-transitory, computer-readable storage medium storing a portion of computer-readable program code, the portion of which, when executed on one or more processors, enables the one or more processors to implement an AI-assisted host-specific Python scripting system, the AI-assisted host-specific Python scripting system comprising: A generative AI (GAI) system communicatively connected to a host system via a host system interface, wherein the GAI system is specifically trained to provide Python development information for generating Python scripts in the Python development system to implement host system functions, and wherein the GAI system is configured to receive natural language user queries related to Python scripts for a given host system function and return Python development information related to the given host system function.

16. The computer program product according to claim 15, wherein, The GAI system includes chatbots.

17. The computer program product according to claim 15, wherein, The host system is an Enterprise Asset Management (EAM) system.

18. The computer program product according to claim 15, wherein, The Python development information includes at least one of a complete Python script or a Python script template.

19. The computer program product according to claim 15, wherein, The GAI system is trained and / or retrained using actual or simulated queries of the host system's functionality. Optionally, the training and / or retraining includes human expert feedback to allow the GAI system to benefit from expert input.

20. The computer program product according to claim 15, wherein, The Python script is executed within the Python development system and performs host system functions through the interface between the Python development system and the host system. Optionally, the Python development system and the host system are connected communicatively via a representative state transition (REST) ​​API.

21. The computer program product according to claim 15, wherein, The GAI system receives natural language user queries via the host system interface.

Images