Asset management

Abstract

A system may include an application server to host an application program, and the application program may include one or more modules to associate an asset with location data, manufacture data, and industry data for input into an artificial intelligence ("AI") module. Location data may include a physical location of the asset. The system may further include an AI module communicably coupled to the one or more modules, and the AI module may receive the manufacture data, the user data, and the industry data from the one or more modules. The AI module may generate a predictive maintenance schedule for the asset based on the manufacture data and the industry data. The AI module may receive the location data from the one or more modules and adjust the predictive maintenance schedule based on the location data.

Description

ASSET MANAGEMENTCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 642,457, filed May 3rd, 2024 and titled “Artificial Intelligence System for Monitoring and Managing Warranty and Maintenance Information” by Christopher C. Brady.BACKGROUND

[0002] Products have a limited lifespan due to natural deterioration, repeated use, and general wear-and-tear. It is common that over time products may fail after extensive use for problems that could have been remedied using preventative maintenance. Often, owners of the product(s) are unaware of underlying problems and maintenance is not performed accordingly.

[0003] Additionally, many products are sold with a warranty agreement which benefits the consumer by forming an agreement between the provider and consumer to replace or repair a product if it becomes damaged or otherwise inoperable within a specified period of time. The warranty agreement benefits both parties by instilling trust in the consumer, which hopefully leads to a purchase of the product, and limiting the time period during which the consumer can make a claim, which gives certainty to the provider. However, consumers are often unaware of how to maximize such warranty benefits.

[0004] Considering the above, and multiplying the effects over an enormous number of products, it is difficult for both consumers and suppliers to manage all the various aspects of products and their associated maintenance schedules.SUMMARY

[0005] A system for asset management may include an application server to host an application program, and the application program includes one or more modules to associate an asset with location data, manufacture data, and industry data for input into an artificial intelligence (“Al) module. Location data may include a physical location of the asset. The system may further include an Al module communicably coupled to the one or more modules, and the Al module may receive the manufacture data, the user data, and the industry data from the one or more modules.The Al module may generate a predictive maintenance schedule for the asset based on the manufacture data and the industry data. The Al module may receive the location data from the one or more modules and adjust the predictive maintenance schedule based on the location data.

[0006] A method for asset management may include associating an asset with location data, manufacture data, and industry data, and the location data may include a physical location of the asset. The method may further include generating a predictive maintenance schedule for the asset based on the manufacture data and the industry data. The method may further include adjusting the predictive maintenance schedule based on the location data and outputting at least a portion of the predictive maintenance schedule for display.

[0007] A non-transitory computer-readable medium for asset management may store instructions that, when executed by one or more processors, cause the one or more processors to associate an asset with location data, manufacture data, and industry data. The location data may include a physical location of the asset. The one or more processors may be further caused to generate a predictive maintenance schedule for the asset based on the manufacture data and the industry data. The one or more processors may be further caused to adjust the predictive maintenance schedule based on the location data, and output at least a portion of the predictive maintenance schedule for display.BRIEF DESCRIPTION OF THE DRAWINGS

[0008] asset management is disclosed herein. In the drawings:

[0009] Figure 1 is a block diagram of a system, networked with devices, for asset management in accordance with at least some illustrative embodiments;

[0010] Figure 2 is a block diagram of a system for asset management in accordance with at least some illustrative embodiments;

[0011] Figure 3 is a flow diagram of a portion of asset management in accordance with at least some illustrative embodiments;

[0012] Figure 4 is a flow diagram of a portion of asset management in accordance with at least some illustrative embodiments;

[0013] Figure 5 is a user interface of a portion of asset management in accordance with at least some illustrative embodiments;

[0014] Figures 6A and 6B are user interfaces of a portion of asset management in accordance with at least some illustrative embodiments;

[0015] Figure 7 is a user interface of a portion of asset management in accordance with at least some illustrative embodiments; and

[0016] Figure 8 is a user interface of a portion of asset management in accordance with at least some illustrative embodiments.

[0017] It should be understood, however, that the specific embodiments given in the drawings and detailed description thereto do not limit the disclosure. On the contrary, they provide the foundation for one of ordinary skill to discern the alternative forms, equivalents, and modifications that are encompassed together with one or more of the given embodiments in the scope of the appended claims.NOTATION AND NOMENCLATURE

[0018] Certain terms are used throughout the following description and claims to refer to particular system components and configurations. As one of ordinary skill will appreciate, companies may refer to a component by different names. This document does not intend to distinguish between components that differ in name but not function. In the following discussion and in the claims, the terms “including” and “comprising” are used in an open-ended fashion, and thus should be interpreted to mean “including, but not limited to . . . ”.DETAILED DESCRIPTION

[0019] The embodiments provided herein relate to asset management. Therefore, in at least one embodiment, a system includes at least one user computing device in operable connection with a user network. An application server is in operable communication with the user network to host an application program collecting, organizing, and disseminating asset information to generate, via an artificial intelligence (“Al”) module, a maintenance plan for products, which are also referred to as assets herein. A product analysis module transmits asset information to the Almodule, and the Al module generates a predictive maintenance schedule and calculates a lifetime cost associated with the asset. An asset module identifies the location of each asset and associates the asset with location data, manufacture data, user data, and industry data to dynamically adjust, via the Al module, the predictive maintenance schedule. Accordingly, the predictive maintenance schedule is optimized or tailored to the asset in very fine detail. For example, the predictive maintenance schedules for the same model of asset in Florida and Maine will vary considerably. Similarly, the predictive maintenance schedules for the same model of asset used frequently or infrequently will vary considerably. These are two simple variables of the hundreds that are monitored in real time by the system and disclosed herein. Additionally, these variables are independent, but as also disclosed herein, the system accounts for dependent variables as well. Also, the system provides a means for generating predictive maintenance schedules at scale for numerous and various assets leading to proportional savings. Specifically, the Al module may autonomously schedule maintenance procedures for each asset to ensure they are maintained and function properly throughout the lifespan of the asset. The system may aid the consumer in advantageously maintaining products to reduce overall lifetime cost of the product by automatically scheduling maintenance and / or servicing and maximizing warranty benefits. In this way, a chain of quick service restaurants (“QSRs”) may implement the system to monitor hundreds of stores for savings in the millions of dollars.

[0020] As mentioned, the predictive maintenance schedule may be adjusted based on location data associated with the specific asset being serviced. However, the laborious input of such data by hand is not necessary. Specifically, the asset knowledge module may receive location data identified by the computing device of maintenance personnel. This process is performed by the maintenance personnel scanning a label and / or identification marker on the asset, which can then be geotagged by the device without the input of the personnel, to identify its specific location. This location data may then be associated with manufacture data such as the specific model number, serial number, etc. associated with the label.

[0021] Similarly, warranty information need not be input manually. Specifically, the system may provide an automated means for determining if the product, component thereof, or incident is covered under a warranty agreement. This determination may be used by the consumer and / or the provider to assess and determine a suitable solution to the problem at hand.

[0022] Similarly, service updates may be automatic. Specifically, the Al module may autonomously schedule maintenance procedures for each product to ensure they are maintained and function properly throughout the lifespan of the product. In this way, the system provides an efficient means of managing product maintenance, servicing, and / or replacement by analyzing product information to reduce the lifetime cost of the product via maintenance, warranty benefit maximization, and optimized repair or replace decisions. This is accomplished via each product’s specific location, manufacture, user, and industry data to reduce the cost of owning, servicing, and / or replacing products. The figures describe how predictive maintenance is implemented in various embodiments.

[0023] Figure 1 illustrates an example of a computer system 100 that may be utilized to execute various procedures, implement the system described herein, including the processes described herein, and perform instructions on non-transitory computer-readable mediums. The computer system 100 includes a standalone computer or mobile computing device, a mainframe computer system, a workstation, a network computer, a desktop computer, a laptop, or the like. The computing device 100 can be embedded in another device, e.g., a mobile telephone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device (e.g., a universal serial bus (USB) flash drive).

[0024] In some embodiments, the computer system 100 includes one or more processors 110 coupled to a memory 120 through a system bus 180 that couples various system components, such as input / output (VO) devices 130, to the processors 110. The bus 180 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. For example, such architectures include Industry Standard Architecture (“ISA”) bus, Micro Channel Architecture (“MCA”) bus, Enhanced ISA (“EISA”) bus, Video Electronics Standards Association (“VESA”) local bus, and Peripheral Component Interconnect (“PCI”) bus, also known as Mezzanine bus.

[0025] In some embodiments, the computer system 100 includes one or more input / output (VO) devices 130, such as video device(s) (e.g., a camera), audio device(s), and display(s) are in operable communication with the computer system 100. In some embodiments, similar VO devices 130 may be separate from the computer system 100 and may interact with one or more nodes of the computer system 100 through a wired or wireless connection, such as over a network interface.

[0026] Processors 110 suitable for the execution of non-transitory computer readable program instructions include both general and special purpose microprocessors and any one or more processors of any digital computing device. For example, each processor 110 may be a single processing unit or a number of processing units and may include single or multiple computing units or multiple processing cores. The processor(s) 110 can be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and / or any devices that manipulate signals based on operational instructions. For example, the processor(s) 110 may be one or more hardware processors and / or logic circuits of any suitable type specifically programmed or configured to execute the algorithms and processes described herein. The processor(s) 110 can be configured to fetch and execute computer readable program instructions stored in the computer-readable media, which can program the processor(s) 110 to perform the functions described herein.

[0027] In this disclosure, the term “processor” can refer to substantially any computing processing unit or device, including single-core processors, single-processors with software multithreading execution capability, multi-core processors, multi-core processors with software multithreading execution capability, multi-core processors with hardware multithread technology, parallel platforms, and parallel platforms with distributed shared memory. Additionally, a processor can refer to an integrated circuit, an application specific integrated circuit (“ASIC”), a digital signal processor (“DSP”), a field programmable gate array (“FPGA”), a programmable logic controller (“PLC”), a complex programmable logic device (“CPLD”), a discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. Further, processors can exploit nano-scale architectures, such as molecular and quantum-dot based transistors, switches, and gates, to optimize space usage or enhance performance of user equipment. A processor can also be implemented as a combination of computing processing units.

[0028] In some embodiments, the memory 120 includes computer-readable application instructions 140, configured to implement some embodiments described herein, and a database 150, including various data accessible by the application instructions 140. In some embodiments, the application instructions 140 include software elements corresponding to one or more of the various embodiments described herein. For example, application instructions 140 may be implemented in various embodiments using any desired programming language, scriptinglanguage, or combination of programming and / or scripting languages (e.g., Android, C, C++, C#, JAVA, JAVASCRIPT, PERL, etc ).

[0029] In this disclosure, terms “store,” “storage,” “data store,” data storage,” “database,” and substantially any other information storage component relevant to operation and functionality of a component are utilized to refer to “memory components,” which are entities embodied in a “memory,” or components including a memory. Those skilled in the art would appreciate that the memory and / or memory components described herein can be volatile memory, nonvolatile memory, or both volatile and nonvolatile memory. Nonvolatile memory can include, for example, read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable ROM (EEPROM), flash memory, or nonvolatile random access memory (RAM) (e.g., ferroelectric RAM (FeRAM). Volatile memory can include, for example, RAM, which can act as external cache memory. The memory and / or memory components of the systems or computer-implemented methods can include the foregoing or other suitable types of memory.

[0030] Generally, a computing device will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass data storage devices; however, a computing device need not have such devices. The computer readable storage medium (or media) can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium can be, for example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium can include: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. In this disclosure, a computer readable storage medium is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

[0031] In some embodiments, the steps and actions of the application instructions 140 described herein are embodied directly in hardware, in a software module executed by a processor, in a non-transitory computer-readable medium, or in a combination of the preceding. A software module may reside in RAM, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium may be coupled to the processor 110 such that the processor 110 can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integrated into the processor 110. Further, in some embodiments, the processor 110 and the storage medium may reside in an Application Specific Integrated Circuit (ASIC). In the alternative, the processor and the storage medium may reside as discrete components in a computing device. Additionally, in some embodiments, the events or actions of a method or algorithm may reside as one or any combination or set of codes and instructions on a machine-readable medium or computer-readable medium, which may be incorporated into a computer program product.

[0032] In some embodiments, the application instructions 140 for carrying out operations of the present disclosure can be assembler instructions, instruction-set-architecture (“ISA”) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C#, C++, or the like, and procedural programming languages, such as the “C” programming language or similar programming languages. The application instructions 140 can execute entirely on the user’s computer, partly on the user’s computer, as a stand-alone software package, partly on the user’s computer and partly on a remote computer, or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (“LAN”) or a wide area network (“WAN”), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (“FPGA”), or programmable logic arrays (“PLA”) can execute the computer readable program instructions by utilizing state information of the computer readableprogram instructions to personalize the electronic circuitry, in order to perform aspects of the present disclosure.

[0033] In some embodiments, the application instructions 140 can be downloaded to a computing / processing device from a computer readable storage medium, or to an external computer or external storage device via a network 190. A network adapter card or network interface in each computing / processing device receives computer readable program instructions from the network and forwards the computer readable application instructions 140 for storage in a computer readable storage medium within the respective computing / processing device.

[0034] In some embodiments, the computer system 100 includes one or more interfaces 160 that allow the computer system 100 to interact with other systems, devices, or computing environments. In some embodiments, the computer system 100 includes a network interface 165 to communicate with a network 190. In some embodiments, the network interface 165 is configured to allow data to be exchanged between the computer system 100 and other devices attached to the network 190, such as other computer systems, or between nodes of the computer system 100. In various embodiments, the network interface 165 may support communication via wired or wireless general data networks, such as any suitable type of Ethernet network, for example, via telecommunications / telephony networks such as analog voice networks or digital fiber communications networks, via storage area networks such as Fiber Channel SANs, or via any other suitable type of network and / or protocol. Other interfaces include the user interface 170 and the peripheral device interface 175.

[0035] In some embodiments, the network 190 corresponds to a local area network (“LAN”), wide area network (“WAN”), the Internet, a direct peer-to-peer network (e.g., device to device Wi-Fi, Bluetooth, etc.), and / or an indirect peer-to-peer network (e.g., devices communicating through a server, router, or other network device). The network 190 may include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and / or edge servers. The network 190 can represent a single network or multiple networks. In some embodiments, the network 190 used by the various devices of the computer system 100 is selected based on the proximity of the devices to one another or some other factor. For example, when a first user device and second user device are near each other (e.g., within a threshold distance, within direct communication range, etc.), the first user device mayexchange data using a direct peer-to-peer network. But when the first user device and the second user device are not near each other, the first user device and the second user device may exchange data using a peer-to-peer network (e.g., the Internet). The Internet refers to the specific collection of networks and routers communicating using an Internet Protocol (“IP”) including higher level protocols, such as Transmission Control Protocol / Internet Protocol (“TCP / IP”) or the Uniform Datagram Packet / Intemet Protocol (“UDP / IP”).

[0036] Any connection between the components of the system may be associated with a computer-readable medium. For example, if software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (“DSL”), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. As used herein, the terms “disk” and “disc” include compact disc (“CD”), laser disc, optical disc, digital versatile disc (“DVD”), floppy disk, and Blu-ray disc; in which “disks” usually reproduce data magnetically, and “discs” usually reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer- readable media. In some embodiments, the computer-readable media includes volatile and nonvolatile memory and / or removable and non-removable media implemented in any type of technology for storage of information, such as computer-readable instructions, data structures, program modules, or other data. Such computer-readable media may include RAM, ROM, EEPROM, flash memory or other memory technology, optical storage, solid state storage, magnetic tape, magnetic disk storage, RAID storage systems, storage arrays, network attached storage, storage area networks, cloud storage, or any other medium that can be used to store the desired information and that can be accessed by a computing device. Depending on the configuration of the computing device, the computer-readable media may be a type of computer- readable storage media and / or a tangible non-transitory media to the extent that when mentioned, non-transitory computer-readable media exclude media such as energy, carrier signals, electromagnetic waves, and signals per se.

[0037] In some embodiments, the system is world-wide-web (“www”) based, and the network server is a web server delivering HTML, XML, etc., web pages to the computing devices. In other embodiments, a client-server architecture may be implemented, in which a network serverexecutes enterprise and custom software, exchanging data with custom client applications running on the computing device.

[0038] In some embodiments, the system can also be implemented in cloud computing environments. In this context, “cloud computing” refers to a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned via virtualization and released with minimal management effort or service provider interaction, and then scaled accordingly. A cloud model can be composed of various characteristics (e.g., on- demand self-service, broad network access, resource pooling, rapid elasticity, measured service, etc ), service models (e g., Software as a Service (“SaaS”), Platform as a Service (“PaaS”), Infrastructure as a Service (“laaS”), and deployment models (e.g., private cloud, community cloud, public cloud, hybrid cloud, etc.).

[0039] As used herein, the term “add-on” (or “plug-in”) refers to computing instructions configured to extend the functionality of a computer program, where the add-on is developed specifically for the computer program. The term “add-on data” refers to data included with, generated by, or organized by an add-on. Computer programs can include computing instructions, or an application programming interface (“API”) configured for communication between the computer program and an add-on. For example, a computer program can be configured to look in a specific directory for add-ons developed for the specific computer program. To add an add-on to a computer program, for example, a user can download the add-on from a website and install the add-on in an appropriate directory on the user’s computer.

[0040] In some embodiments, the computer system 100 may include a user computing device 145, an administrator computing device 185 and a third-party computing device 195 each in communication via the network 190. The administrator computing device 185 is utilized by an administrative user to moderate content and to perform other administrative functions. The third- party computing device 195 may be utilized by third parties to receive communications from the user computing device, transmit communications to the user via the network, and otherwise interact with the various functionalities of the system.

[0041] Figure 2 illustrates an example architecture for the application program 200 operated via the computing system 100. The computer system 100 includes several modules, andthe modules are configured to execute the functionalities of the application program 200 in various embodiments. For example, a database module 204 is configured to facilitate how data is stored and managed in one or more databases. In some embodiments, the application program 200 includes one or more of a communication module 202, a database module 204, an Al module 210, a user module 212, a product analysis module 214, a display module 216, an asset knowledge module 218, and a reports module 220. The modules may associate an asset with location data, manufacture data, user data, and industry data for input into the Al module 210.

[0042] In some embodiments, the communication module 202 is configured for receiving, processing, and transmitting a user command and / or one or more data streams. In such embodiments, the communication module 202 performs communication functions between various devices, including the user computing device 145, the administrator computing device 185, and a third-party computing device 195. In some embodiments, the communication module 202 is configured to allow one or more users of the system, including a third-party, to communicate with one another. For example, the communications module 202 is configured to maintain one or more communication sessions with one or more servers, the administrative computing device 185, and / or one or more third-party computing device(s) 195.

[0043] In some embodiments, the communication module 202 may be used to communicate with a service provider, such as maintenance personnel. The communication module 202 may automatically, via input from the Al module 210, schedule maintenance, inspection, and / or replacement of the product at predetermined time intervals. For example, the communication module 202 may respond to adjustment of the predictive maintenance schedule by scheduling or rescheduling events for maintenance personnel based on the adjustment. In some embodiments, the communication module 202 may transmit scheduling requests, maintenance orders, or service confirmations via email, SMS, or through a secure API integration with a third- party contractor portal. The communication module 202 may also log service acknowledgments, confirm technician arrival and task completion, and update the asset’s maintenance history accordingly. In some embodiments, the communication module 202 may trigger alerts if the assigned service provider fails to confirm a scheduled task within a defined response window, allowing the system to escalate the task to an alternate provider or supervisory personnel. Additionally, the communication module 202 may synchronize with a user interface to visually display scheduled events and permit manual overrides or reassignment by administrative users.

[0044] In some embodiments, a database module 204 is configured to facilitate the storage, management, and retrieval of data to and from one or more storage mediums such as the one or more internal databases described herein. For example, the database module 204 may be coupled to an external storage system and configured to apply changes to one or more databases. In some embodiments, the database module 204 includes a search module component for searching through thousands of data sources stored in different locations.

[0045] In some embodiments, the database module 204 may be operable to transmit and receive industry data related to products, product components, maintenance requirements related to the product, warranty information, and the like. The industry data may include aggregated failure rates, updated service bulletins, manufacturer recommendations, recall notices, and anonymized performance benchmarks derived from similar products used in comparable environments. This data may be retrieved from external sources such as OEM databases, industry consortia, technical publications, or cloud-based repositories. In some embodiments, the Al module 210 may analyze the received industry data in combination with asset-specific usage patterns to refine or adjust the predictive maintenance schedule. For example, if industry data indicates that a particular component has a higher-than-expected failure rate after a certain number of operational hours, the Al module 210 may shorten the maintenance interval or insert an additional inspection task into the schedule without human input. Similarly, if new manufacturer guidelines recommend modified servicing procedures or upgraded replacement parts, the Al module 210 may trigger a system -wide update to ensure compliance without human input. These adjustments ensure that the system remains adaptive and responsive to real time data thereby improving asset reliability and reducing downtime.

[0046] In some embodiments, the database module 204 may be operable to transmit and receive location data to determine adjustments in the predictive maintenance schedules based on the physical location of the asset (e.g. an appliance). For example, if the location data suggests that the asset (such as an air conditioning unit) is located in a hot environment (e.g. Phoenix), the analysis module may infer that the air conditioning unit is utilized more often than if it were located in a cooler environment (e.g. San Diego). Accordingly, the Al module 210 may reduce the interval between recommended maintenance events, increase the frequency of inspections, prompt early replacement of high-wear components, and / or the like without human input. In other embodiments, location data may be used to infer environmental conditions such as humidity, altitude, salinity(e.g., coastal proximity), air quality, or exposure to industrial contaminants. These conditions may accelerate degradation of specific components and influence corrosion rates, airflow obstruction, or electronic failure modes. Additionally, location data may be cross-referenced with regional utility costs or regulatory requirements thus allowing the system to prioritize maintenance actions that improve energy efficiency or ensure code compliance. The location data may be obtained via GPS, Wi-Fi triangulation, user-entered inputs, or integration with facility management systems. By incorporating geospatial intelligence, the system 100 tailors asset-specific maintenance plans to real-world conditions thereby improving accuracy and extending useful life.

[0047] In some embodiments, the database module 204 is capable of receiving inputs from maintenance personnel, administrators, and / or the owner of the asset. Furthermore, the database module 204 may receive user data related to the user’s habits, preferences, etc., which are associated with the asset. For example, the user data may relate to how often the user utilizes an air conditioning unit, what temperature thresholds the user operates the air conditioning unit, and the like. User data may also include time-of-day usage patterns, frequency of short-cycling behavior, and manual overrides of automated settings, which correlate with specific wear-and-tear profiles. User data may further include interaction patterns with maintenance alerts, responsiveness to service reminders, and prior history of deferring or accelerating repairs. These behavioral indicators allow the Al module 210 to assess the likelihood of compliance with maintenance recommendations, thereby allowing it to prioritize more proactive interventions for high-risk or high-impact users by adjusting the predictive maintenance schedule for the associated asset. Additionally, user-entered comments or manual service logs may serve as user data for the Al module 210 thus helping to refine future maintenance predictions and enabling personalized guidance.

[0048] In some embodiments, the database module 204 is in communication with an object data management system (“ODMS”). The ODMS stores and manages manufacture data including model number, serial number, description of the asset, and the like. The manufacture data may further include part specifications, operating tolerances, and component-level failure thresholds. Furthermore, the manufacturer data may define service life expectations and end-of-life triggers for specific components thus allowing the predictive maintenance system 100 to model degradation curves more accurately. Ultimately, integration with the ODMS enables the system100 to provide maintenance guidance that is not only predictive but also compliant with technical standards.

[0049] In some embodiments, the Al module 210 is operable to determine a suitable maintenance schedule for a product and analyze warranty information for the product to output a suitable maintenance schedule associated with the product. In addition to preventative maintenance, the product maintenance schedule may include repair and / or replacement of the product as a whole or components that make up the product. The Al module 210 may receive information from the database module 204 to determine a suitable maintenance schedule for the product using disparate sources. In addition to the manufacture data, user data, industry data, and location data, the Al module 210 may utilize product pricing information, component pricing information, and / or labor pricing information to determine a cost-effective solution for product repair, service, or replacement.

[0050] In some embodiments, the Al module 210 may be used to analyze images received from maintenance personnel to verify the authenticity of the services performed on the asset. For example, if a pool fdter is to be replaced, the maintenance personnel may take images of the old filter and new filter. The Al module 210 may then analyze the images to confirm that the proper maintenance was performed (i.e. the new pool filter was properly installed). In some embodiments, the image analysis is not performed using strict pixel-by-pixel comparison, which would be sensitive to variations in lighting, angle, or device camera resolution. Instead, the system 100 utilizes a feature-based image recognition technique, where the Al module 210 identifies and extracts key visual features or reference patterns from each image — such as shape contours, spatial relationships, texture gradients, and component layout — using algorithms such as scale-invariant feature transform (“SIFT”), speeded-up robust features (“SURF”), or deep convolutional neural networks (“CNNs”). These features are then matched against a model or reference set representing the correct installation of the asset component. The analysis accounts for variations in orientation or viewpoint by applying geometric transformations, such as affine or perspective normalization, to standardize the reference and comparison images. In some embodiments, the Al module 210 also utilizes object detection and classification layers to identify the presence and correct positioning of critical parts (e.g. hose clamps, filter caps, housing seals) and to confirm that the image includes expected environmental context (e.g. the component is installed in a pool pump housing rather than a warehouse shelf). The result is a confidence score or pass / fail determinationindicating whether the submitted image matches the expected outcome for a completed maintenance action even if the image was taken from the opposite side or at a rotated angle. This technique enhances reliability and usability by allowing maintenance personnel to submit verification images without requiring standardized photographic conditions thereby streamlining field operations while preserving verification integrity.

[0051] In some embodiments, the Al module 210 may be used to verify the identity of the maintenance personnel. For example, the Al module 210 may employ biometric recognition techniques such as facial recognition, voiceprint analysis, or gait detection to authenticate the identity of the maintenance personnel. Specifically, the system may prompt the technician to take a picture of themselves, record a short audio clip, or capture a brief video before or after performing the service, which is then analyzed against a database of authorized personnel to verify identity. In addition, the Al module 210 may use metadata from image or video files — such as GPS coordinates, device ID, and creation time — to correlate personnel identity with the service event and its physical location. This information may be referenced with the images showing and confirming the proper maintenance was executed. The Al module 210 may also be used to automatically log time stamps related to the period of time during which maintenance was performed. The time stamps may include both start and end times, which are automatically generated upon initiation and completion of the maintenance task within the system interface or inferred from file timestamps when images or other documentation are uploaded to the system 100. This creates a secure and auditable record of who performed the service, when it was performed, and how it was verified. In some embodiments, the Al module 210 may also crossreference the personnel identity, time log, and image verification results to detect inconsistencies or potential fraud. For example, if the same technician ID appears at two geographically distant service sites within an unfeasible time window, the system may trigger an alert or flag the record for administrative review. This integrated identity and time-verification functionality supports accurate labor tracking, strengthens warranty compliance, and improves accountability within third-party service networks.

[0052] In some embodiments, the Al module 210 may be used to infer location information and modify the predictive maintenance schedules and suggested maintenance actions based on the location of the asset. To determine the location of the asset, the asset is provided with a label indicating the model number, serial number, brand, etc. that identifies the asset. The label mayinclude a scannable code (or other code which may be entered into the computing device utilized by the maintenance personnel). Scanning the label will allow the system 100 to determine the location of the maintenance personnel via the location-enabled computing device being utilized by the maintenance personnel. This information is then logged and stored, via the database module 204, to accurately define the location of the asset. In some embodiments, the location information may be captured using GPS, Wi-Fi triangulation, cellular tower proximity, or other geolocation methods integrated into the mobile device or computing device. The location coordinates may be cross-referenced with an asset registry or facility map to associate the asset with a specific building, zone, or service region. In instances where multiple assets are located in proximity, the system may also prompt the technician to confirm the asset’s identity by visually matching asset attributes (e.g. model, serial number) or using image recognition of the asset itself.

[0053] The logged location data may be used by the Al module 210 to adjust the asset’s predictive maintenance schedule based on regional environmental factors such as temperature, humidity, elevation, or local utility rates. For example, an asset operating in a coastal region may be assigned a more aggressive corrosion inspection interval due to increased salt exposure, while assets in high-altitude locations may experience accelerated wear on pressure-sensitive components. In some embodiments, location inference also improves system security by validating that a maintenance event occurs at the expected physical location. If a label is scanned and a device reports a geolocation inconsistent with the asset’s assigned location, the system 100 may generate a discrepancy alert or restrict access to maintenance records. Additionally, accurate location tagging supports fleet-wide reporting, compliance auditing, and automated scheduling across distributed assets thus making the platform suitable for enterprise- scale deployment.

[0054] In some embodiments, the user module 212 facilitates the creation of a user account for the application system. The user account may permit the user to input user information, product information, and the like. For example, an owner of a property may input products (e.g. appliances) which are within the property. The Al module 210 may then be used to analyze the products, product warranty information, maintenance information, and the like in order to output a maintenance plan for each product the user has entered into the system. In some embodiments, the user module 212 may support role-based access allowing different users (e.g. property owners, facility managers, technicians, or administrators) to create and manage accounts with varying levels of access to data and functionality. Users may be permitted to manage one or moreproperties, each containing a collection of registered products or assets, which may be grouped by location, usage type, or ownership status. The user module 212 may further be configured to synchronize data from external systems, such as manufacturer registration platforms, smart home networks, or warranty providers, allowing users to automatically populate product records with minimal manual entry. In some embodiments, the module 212 may support photo-based product registration, where a user captures an image of the asset label, and the system 100 extracts relevant metadata (e.g. model number, serial number, installation date) using optical character recognition (“OCR”) and image analysis. Once products are registered, the Al module 210 may tailor the maintenance plan for each product based on the user’s usage habits, environmental context, and warranty constraints. The system may generate personalized maintenance schedules, notifications, and recommendations for repair or replacement. These schedules may also be adjusted over time based on user interactions, system data, or manufacturer updates.

[0055] In some embodiments, a product analysis and maintenance module 214 is operable to analyze industry data including product components, maintenance requirements, warranty information, and product pricing. The product analysis and maintenance module 214 may be in communication with the Al module 210 to collect, organize, and disseminate industry data that can be used to adjust a maintenance schedule to be optimized for the specific product. In some embodiments, the product analysis and maintenance module 214 may parse data obtained from industry specifications, part catalogs, warranty documentation, and / or repair logs to generate a component-level understanding of the asset. This component hierarchy may include part numbers, expected lifespans, service dependencies, and compatibility with replacement parts. The module 214 may also analyze differences between model variants to ensure that maintenance recommendations are appropriately tailored to the exact version of the product. The Al module 210 may employ rules-based logic and Al-assisted classification to identify which components are considered high-priority for preventive maintenance, which are commonly subject to failure, and which may be addressed during scheduled downtime or bundled service visits. Using this analysis, the Al module 210 optimizes the maintenance schedule to balance operational uptime, costefficiency, and warranty compliance.

[0056] In some embodiments, the product analysis and maintenance module 214 may be operable to automatically update (i.e. without human input) its component databases and maintenance guidelines when new manufacturer bulletins, product advisories, or industrystandards are released. It may also support real-time recalculation of maintenance priorities based on data received from other modules, such as environmental conditions (via the database module 204), user behavior (via the user module 212), or service verification (via the communication module 202). Additionally, the Al module 210 may interface with procurement systems or pricing databases to provide cost-sensitive recommendations, such as suggesting proactive replacement of low-cost high-failure parts while deferring expensive replacements with no immediate risk. By leveraging both historical and contextual data, the product analysis and maintenance module 214 ensures that maintenance strategies are highly specific, updated in real time, and economically optimized for each individual asset.

[0057] In some embodiments, the display module 216 is configured to output for display one or more graphic user interfaces, including one or more user interfaces, one or more consumer interfaces, one or more video presenter interfaces, and the like. In some embodiments, the display module 216 is configured to temporarily generate and display various pieces of information in response to one or more commands or operations. The various pieces of information or data generated and displayed may be refreshed and replaced with different content upon the receipt of different commands or operations in some embodiments. In some embodiments, the display module 216 may output real-time data visualizations, alerts, maintenance timelines, warranty status indicators, service verification screens, or cost projection summaries based on the context of the user’s interaction. The module may generate dashboards or widget-based layouts that adjust in response to user role, asset type, location, or service state. For example, a maintenance technician may be shown checklists, image upload prompts, and confirmation buttons, while a property owner may instead be presented with high-level summaries, risk assessments, and historical cost charts. In some embodiments, the display module 216 may be integrated with the Al module 210 to prioritize and personalize the content displayed such as highlighting overdue service items, recommending actionable maintenance tasks, or generating interactive hypothetical simulations related to product failure, repair costs, or warranty expiration. Additionally, the display module 216 may be configured to support touch, voice, or gesture-based inputs to facilitate mobile or hands-free use.

[0058] The display module 216 may further be configured to render content conditionally based on triggers received from other system components. For instance, upon scanning a product label or taking a picture of an asset, the module may automatically generate a maintenance recordentry screen with pre-filled product details and geolocation tags. In some embodiments, the display module 216 may also provide educational overlays or embedded video content to guide users through service procedures or troubleshooting steps.

[0059] In some embodiments, the asset knowledge module 218 may receive data feedback input by the maintenance personnel as user data. In some embodiments, the asset knowledge module 218 aggregates and stores asset-specific operational history, including observed failure modes, component replacement frequency, maintenance intervals, environmental conditions, and service outcomes. This cumulative user dataset is enriched over time through ongoing feedback provided by both automated analytics and manual inputs from technicians, administrators, and users. The Al module 210 may utilize this data to improve the precision of future maintenance recommendations, support root cause analysis, and identify recurring patterns across similar asset types, models, or geographic regions. For example, if multiple instances of the same product model exhibit early failure of a particular component, the module 210 may flag the pattern and update the predictive maintenance schedules accordingly. This enables the system 100 to scale highly contextual and evidence-based predictive maintenance to thousands of assets.

[0060] Additionally, the asset knowledge module 218 may serve as a structured repository that facilitates cross-asset comparison, benchmarking, and trend visualization. It may also be queried by other system modules to retrieve prior service outcomes, confirm component compatibility, or reference service documentation associated with specific failure events. In some embodiments, the module supports machine learning routines that retrain predictive algorithms based on confirmed outcomes thereby enhancing the Al module’s 210 decision-making accuracy over time. The asset knowledge module 218 may also be used to inform compliance audits, warranty claims processing, and performance scoring of service providers or asset types based on historical effectiveness and reliability.

[0061] In some embodiments, the reports module 220 is operable to generate automated reports related to an asset, executed service, as well as other reportable information. These reports may include detailed records of maintenance activities, warranty status, upcoming service recommendations, and cost summaries. In some embodiments, the reports module 220 is configured to compile data from multiple system components, including the Al module 210,product analysis and maintenance module 214, communication module 202, and asset knowledge module 218, to present a comprehensive and context-aware snapshot of an asset’s lifecycle status.

[0062] The reports module 220 may generate different types of reports based on user role or reporting context. For example, a property owner may receive a high-level asset summary highlighting upcoming maintenance and total cost of ownership while a technician or service provider may receive a detailed breakdown of individual component performance, service history, and time-stamped verification logs. In some embodiments, reports may include embedded images submitted during service, annotated notes from maintenance personnel, or verification data confirming the identity and location of the service provider.

[0063] Reports may be generated on a scheduled basis (e.g., weekly, monthly, quarterly), on demand, or in response to predefined system triggers, such as warranty expiration, failure prediction thresholds, or regulatory compliance deadlines. The reports module 220 may also support filtering and customization, allowing users to select parameters such as date range, asset type, region, or cost category. Reports may be exported in various formats (e.g. hardcopy, PDF, CSV, XLSX) or accessed via an interactive dashboard view within the application interface. In some embodiments, the reports module 220 may be integrated with external enterprise systems such as ERP, CMMS, or accounting platforms to support streamlined data sharing, billing reconciliation, or performance tracking. Additionally, reports may be distributed to predefined notification groups via email, SMS, or in-app messaging, and may include summary insights or recommendations for corrective action or capital planning.

[0064] Figure 3 and Figure 4 illustrate methods 300, 400 of predictive maintenance in some embodiments, which may include any step or process described herein. Figure 3 illustrates a flowchart of the method 300, while Figure 4 illustrates a flowchart of the method 400 focusing on machine learning and an Al information loop. First, multiple categories of input, labeled Input 1 302, Input 2 304, and Input 3 306, are received, each representing a class of data sources relevant to asset condition and performance. These inputs may originate from external databases, user interactions, loT devices, or third-party systems. Additionally, Manufacture Data 308, User Data 312, Location Data 310, and Industry Data 314 are received. All input types are routed to a central Data Repository 314, which stores, organizes, and normalizes the incoming data for further processing. The Data Repository 314 serves as the foundational layer of the system, aggregatinginformation about asset specifications, geographic conditions, industry-wide trends, and user behavior.

[0065] The Data Repository 314 feeds into an Analysis Engine or Al module 316. This module 316 is responsible for evaluating the incoming data and identifying maintenance risks, performance degradations, or predictive failure indicators. Based on the results of the analysis, a set of Action Items are generated — these may include recommended maintenance tasks, inspection prompts, or replacement advisories. The Action Items module 318 is linked to three other system components: an Item Performer 324, which refers to a technician, automated subsystem, or third- party vendor responsible for executing the action; a Data Feedback module 320, which captures outcome information and performance results from completed tasks; and an Asset Knowledge Module 322, which stores historical performance data, failure patterns, and service history for each individual asset.

[0066] Information from the Item Performer 324 and Data Feedback modules 320 is used to update the Asset Knowledge Module 316. This engine, in turn, feeds into a Real-Time Data Loop 326 positioned at the bottom of the diagram. The Real-Time Data Loop 326 enables continuous refinement of asset-specific predictions and allows the system to adapt dynamically to changing usage patterns, environmental conditions, and service outcomes. The process illustrated in Figure 3 enables personalized, asset-specific maintenance recommendations that evolve over time based on observed behavior and contextual inputs to be provided.

[0067] In Figure 4, a dedicated machine learning and artificial intelligence (Al) feedback loop creates an adaptive and continuously self-improving predictive maintenance method. The elements of Figure 4 largely mirror those of Figure 3, but some processes are shaded for discussion. Inputs are received from multiple data sources — including Manufacture Data 308, Location Data 310, Industry Data 314, and User Data 312 — which are processed through Input 1 302, Input 2 304, and Input 3 306. All inputs are routed into a central Data Repository 314, where they are aggregated and normalized for further processing.

[0068] The Analysis Engine 316 receives the processed data from the repository 314 and produces Action Items 318 based on the predicted needs of specific assets. These Action Items 318 are routed to the Item Performer 324, which executes the maintenance or service activity, and to the Data Feedback module 320, which logs the outcome of the service. A machine learning loop326 emphasizes the role of the Asset Knowledge Module 322 and Real-Time Data Loop 326 in continuously refining the system. As actions are performed and feedback is collected, the Asset Knowledge Module 322 updates its internal models and pushes that updated understanding back into the Data Repository 314. This cycle allows the learning from historical performance, refinement of predictions, and re-weighting of the influence of various input parameters (e g. adjusting the importance of location data for certain product categories).

[0069] Additionally, the Location Data 310 may directly feed both the Data Repository 314 and the feedback loop enabling real time adjustment of environmental assumptions based on geospatial conditions. For example, if the system detects consistent early component degradation in coastal regions, future maintenance schedules may be proactively altered for similarly located assets. The Real-Time Data Loop 326 at the bottom of the diagram enables real time updates to asset profiles and maintenance recommendations.

[0070] Figure 5 illustrates a graphical user interface (“GUI”) of a dashboard view 500 for predictive maintenance. The dashboard 500 serves as a centralized control panel through which users — such as facility managers, service providers, or property owners — can view real-time metrics related to product warranties, actionable maintenance items, asset lifespans, and service records.

[0071] The top portion of the dashboard displays three primary summary panels:

[0072] A Warranties 502 panel showing the total number of warranties in the system (921), along with counts of warranties currently active (673), expiring within 3 months (59), and expired (189). A filtering option allows the user to modify the reporting window (e.g. 3 months).

[0073] An Actionable Items 504 panel displays maintenance actions in various stages of execution. The example shown includes 660 on-track actions, 0 pending in 7 days, and 507 past- due actions out of a total of 1167. The user may filter these by date, status, or responsible performer.

[0074] A Useful Life panel 506 shows projected equipment end-of-life distributions. In the example, 2 assets are expiring in 12 months, 23 in 6 months, and 0 in 3 months, with a total of 556 tracked lifespans.

[0075] Below the primary panels, the interface includes additional panels:

[0076] A Locations panel 508 showing a scrollable list of asset sites (e.g., “Burnsville,” “North Branch”), each associated with an address, enabling geo-specific asset tracking. A Saved Reports panel 510, which contains quick links to pre-generated data summaries such as “Pressure Fryer Report” and “North Branch Useful Life.” A Help Interface panel 512, which enables users to launch a real-time support chat with an automated service bot (e.g., “SRG BOT”) for guidance on using the platform or resolving issues.

[0077] The middle section 514 of the interface supports adding new warranties. This form includes fields such as: Warranty type, Part name, Model and manufacturer names, Serial number, Description and installation date, Warranty duration and Calculated End Date, and Notification group list (for escalating service alerts). The lower section of the GUI displays a tabular summary of existing warranties, showing: Warranty type, Duration (in months), Description (e.g. parts and labor coverage percentage), Installation and warranty end dates (including calculated end dates), Associated notification groups, and Historical access controls.

[0078] The user may interact with drop-down menus or input fields to edit, assign, or archive warranty entries. In some embodiments, the dashboard dynamically refreshes in response to new data or user inputs and is integrated with the Al module to highlight critical or overdue items in real-time.

[0079] Figures 6A and 6B illustrate a GUI 600 configured to display detailed lifecycle analytics and cost modeling for a selected asset. This interface, also referred to as the Asset Detail View, enables the user to examine and edit a comprehensive set of parameters that influence the asset's predictive maintenance schedule, end-of-life forecast, financial planning, and service event coordination. The fields are organized into six logically grouped panels, each corresponding to a specific aspect of the asset's lifecycle management.

[0080] Turning to Figure 6A, the Location Story panel 602 includes a set of environmental and situational variables that are used by the system’s Al module to dynamically adjust the asset’s predicted maintenance schedule. The fields in this section include: Water quality, Altitude, Average room temperature, Outdoor temperature (low), Outdoor temperature (high), Asset location (indoor or outdoor), Asset protection (protected or unprotected), Direct sunlight (yes or no), and Adjacent use of flour (yes or no). These inputs allow the system to account for environmental stressors, corrosion likelihood, ambient operating conditions, and airborneparticulate exposure, all of which may influence service intervals or component longevity. These values may be manually entered or imported through automated data integration such as loT feeds or geolocation databases.

[0081] The Life Story panel 604 provides detailed insight into how the asset is used over time. It includes: Daily use hours, Annual operating days, Total operating hours, Date of first use, Frequency (repeated day patterns), Service action, Select performer (designated service personnel or vendor), and Notification group list (list of personnel to be notified for service events). This information supports modeling of wear patterns, usage-based scheduling, and service accountability. It may be used by the Al module to track performance over time, evaluate reliability, and adjust maintenance thresholds accordingly.

[0082] The Useful Life panel 606 contains fields that describe both manufacturer-predicted and system -calculated estimates of the asset’s remaining operational lifespan. The fields include: Installation date, Condition (current assessed status), Length of life (predicted lifespan), Use type (e.g. high, normal, or light duty), End of life (projected date), Notification lead time, and Retirement date. These values enable proactive lifecycle planning including scheduled replacement, warranty alignment, and budget forecasting. These inputs may also cause early alerts for assets nearing their operational limits or falling outside expected longevity ranges.

[0083] Turning to Figure 6B, the Fix or Replace panel 608 allows comparison of cost and value across multiple lifecycle stages. It includes: Purchase cost, Maintenance and repair cost, Useful life value (calculated as a function of performance and age), and Replacement cost. These figures are used to determine whether continued maintenance or asset replacement is the more economically viable option. Al decision support tools may provide a recommendation based on these metrics.

[0084] The Total Cost of Ownership 610 panel aggregates cost data for the asset(s) and supports higher-level financial reporting. It includes: Purchase cost, Operating cost variance, and Maintenance and repair cost. These fields allow stakeholders to evaluate asset profitability and performance over time thus helping inform fleet-wide decisions or procurement strategies.

[0085] The Depreciation panel 612 provides accounting-relevant values to track asset amortization. It includes: Purchase date, Depreciation end of life, Purchase cost, Depreciation term, Depreciated value, and Undepreciated value. This information can be used for tax planning,balance sheet reporting, and retirement timing. The system may synchronize these values with external enterprise resource planning (“ERP”) tools or export them for audit purposes.

[0086] Figure 6 illustrates an exemplary graphical user interface (GUI) 600 configured to display and manage comprehensive lifecycle data, cost modeling, and predictive maintenance parameters for a specific asset within the system. This interface allows a user — such as a facility manager, technician, or administrator — to review and update asset-specific information across multiple categories, including environmental factors, usage patterns, lifespan projections, cost justification, and depreciation tracking.

[0087] Figures 6A and 6B demonstrate the system’s capability to aggregate operational, environmental, financial, and temporal data to inform real-time Al-driven maintenance strategies and cost optimization. The data shown in this interface may be populated manually, via integration with third-party systems, or updated in real time based on sensor and service log inputs. By correlating these data fields across modules, the system enables intelligent forecasting, automated alerts, and actionable insights to extend asset life and reduce downtime.

[0088] Figure 7 illustrates three mobile GUIs 700 designed to facilitate real-time issue reporting, image-based diagnostics, and remote support communication within the predictive maintenance system. These interfaces are intended for use by on-site personnel, such as technicians or facility staff, enabling them to document problems quickly, initiate service requests, and engage with support personnel through rich media.

[0089] The first interface 702 allows a user to initiate a maintenance request by selecting a problem type from a predefined list and designating a service provider. Below these fields, the interface includes a “Take a Picture” button that allows the user to capture visual evidence of the issue (e.g. a damaged or malfunctioning component). A warning message indicates that providing pictures may expedite diagnosis and reduce repair time or cost. Once the required fields are completed, the user may submit the data by tapping the “Create Service Ticket” button.

[0090] The second interface 704 displays a visual gallery of uploaded images associated with the service request. Multiple images may be added, reviewed, and removed (via delete icons). A button labeled “Create Service Ticket” confirms the submission of the issue report along with all attached images. This visual evidence is stored in the system database and used by the Al engineand service personnel to verify the issue, optimize the required maintenance action, and crossreference with warranty status or asset condition.

[0091] The third interface 706 shows an example of a live video call between a technician and multiple remote support participants. In this embodiment, the system supports multi-party video conferencing where a technician can visually demonstrate the issue (e.g. electrical wiring) in real time while receiving feedback, guidance, or confirmation from technical experts or service coordinators. The interface includes video call controls (e.g., mute, video toggle, camera flip, and end call).

[0092] Figure 8 illustrates a GUI 800 for a Facility Action Item Calculator for predictive maintenance. This interface allows users — such as operations managers or maintenance planners — to assess, organize, and project the annual time and cost associated with recurring maintenance tasks across multiple asset categories and labor types. The calculator incorporates both input and output sections, enabling real-time simulation and planning of facility-level asset care strategies. The first panel 802 of the interface allows users to enter or review maintenance details for a particular asset — in this case, an "Undercounter Refrigeration" unit. The table includes: Actionable Maintenance Tasks (e.g., Clean Air Conditioner, Clean Gasket, Check Thermostat Accuracy), Estimated Time per Action, Frequency of Action Occurrence (e.g., Quarterly, Semi-Annually, Annually), Assigned Performer Category (e.g., Technical Staff, DIY Staff, Authorized Service Agent), and Cost per Action. These inputs allow the system to calculate labor hours, annual frequency, and cost allocation by performer type.

[0093] The second panel 804 aggregates all scheduled maintenance tasks across a specified number of assets — in this case, 78 units. Metrics shown include: Total Annual Maintenance Time: 38.6 hours (or 2,316 minutes), Total Annual Cost: $1,729.00, Total Asset Value: $350,000.00, Percentage of Asset Value Dedicated to Care: 0.494%, and Annual and Daily Cost of Care: $1,729.00 annually or approximately $4.74 per day. This cost modeling allows administrators to justify maintenance budgets, optimize labor allocation, and forecast resource needs.

[0094] The next panel 806 breaks down time and cost by performer category: DIY Staff: 4.70 hours, no cost attributed; Technical Staff: 27.97 hours, $839.00 (72.45% of total cost); and Service Agents: 5.93 hours, $890.00 (15.37% of total cost). This enables strategic decision-makingregarding outsourcing, in-house coverage, and potential cost savings from automation or procedural efficiencies.

[0095] The final panel 808 displays Annual Action Item Load by Store and Technical FTE (Full-Time Equivalent), showing how many hours and stores are supported by a single technical employee. For example: Store: Eagan; Annual Labor Hours / Store: 27.97; Annual Labor Hours: 1,715; and Stores per FTE: 45.99. This data supports workforce planning and staffing decisions across distributed retail or service locations.

[0096] Collectively, the panels in Figure 8 allow for quantitative justification of maintenance practices, cost accountability by labor type, and scalable budgeting across multilocation operations. This calculator integrates with the broader predictive maintenance system by feeding back time, cost, and performance outcomes into the asset knowledge engine and real-time Al learning loop for schedule refinement and resource optimization.

[0097] In various embodiments, assets are appliances, equipment, objects (e.g. storm drains), facility components (e.g. parking stripes), fixtures, furniture, finishes, and the like. In various embodiments, assets are: appliances (e.g. refrigeration units, compressors), equipment (e.g. pool filters), components, objects (e g. storm drains), multi asset systems (e.g. HVAC systems, fire suppression systems), facility-related infrastructure (e.g. parking lot stripes, floor tiles, ceiling panels, lighting systems); furniture, fixtures, finishes, and other items whose maintenance, location, usage, and lifecycle characteristics may be monitored, scheduled, and optimized by the system.

[0098] In this disclosure, the various embodiments are described with reference to the flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products. Those skilled in the art would understand that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer readable program instructions. The computer readable program instructions can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions or acts specified in the flowchart and / or block diagram block or blocks. The computer readable programinstructions can be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein includes an article of manufacture including instructions which implement aspects of the function / act specified in the flowchart and / or block diagram block or blocks. The computer readable program instructions can be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational acts to be performed on the computer, other programmable apparatus, or other device to produce a computer implemented process, such that the instructions that execute on the computer, other programmable apparatus, or other device implement the functions or acts specified in the flowchart and / or block diagram block or blocks.

[0099] In this disclosure, the block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to the various embodiments. Each block in the flowchart or block diagrams can represent a module, segment, or portion of instructions, which includes one or more executable instructions for implementing the specified logical function(s). In some embodiments, the functions noted in the blocks can occur out of the order noted in the Figures. For example, two blocks shown in succession can, in fact, be executed concurrently or substantially concurrently, or the blocks can sometimes be executed in the reverse order, depending upon the functionality involved. In some embodiments, each block of the block diagrams and / or flowchart illustration, and combinations of blocks in the block diagrams and / or flowchart illustration, can be implemented by a special purpose hardware-based system that performs the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

[0100] In this disclosure, the subject matter has been described in the general context of computer-executable instructions of a computer program product running on a computer or computers, and those skilled in the art would recognize that this disclosure can be implemented in combination with other program modules. Generally, program modules include routines, programs, components, data structures, etc. that perform particular tasks and / or implement particular abstract data types. Those skilled in the art would appreciate that the computer- implemented methods disclosed herein can be practiced with other computer system configurations, including single-processor or multiprocessor computer systems, mini-computing devices, mainframe computers, as well as computers, hand-held computing devices (e.g., PDA,phone), microprocessor-based or programmable consumer or industrial electronics, and the like. The illustrated embodiments can be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. Some embodiments of this disclosure can be practiced on a stand-alone computer. In a distributed computing environment, program modules can be located in both local and remote memory storage devices.[00101J In this disclosure, the terms “component,” “system,” “platform,” “interface,” and the like, can refer to and / or include a computer-related entity or an entity related to an operational machine with one or more specific functionalities. The disclosed entities can be hardware, a combination of hardware and software, software, or software in execution. For example, a component can be a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and / or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components can reside within a process and / or thread of execution and a component can be localized on one computer and / or distributed between two or more computers. In another example, respective components can execute from various computer readable media having various data structures stored thereon. The components can communicate via local and / or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one component interacting with another component in a local system, distributed system, and / or across a network such as the Internet with other systems via the signal). As another example, a component can be an apparatus with specific functionality provided by mechanical parts operated by electric or electronic circuitry, which is operated by a software or firmware application executed by a processor. In such a case, the processor can be internal or external to the apparatus and can execute at least a part of the software or firmware application. As another example, a component can be an apparatus that provides specific functionality through electronic components without mechanical parts, and the electronic components can include a processor or other means to execute software or firmware that confers at least in part the functionality of the electronic components. In some embodiments, a component can emulate an electronic component via a virtual machine, e.g., within a cloud computing system.

[0102] The phrase “application” as is used herein means software other than the operating system, such as Word processors, database managers, Internet browsers and the like. Each application generally has its own user interface, which allows a user to interact with a particularprogram. The user interface for most operating systems and applications is a graphical user interface (GUI), which uses graphical screen elements, such as windows (which are used to separate the screen into distinct work areas), icons (which are small images that represent computer resources, such as files), pull-down menus (which give a user a list of options), scroll bars (which allow a user to move up and down a window) and buttons (which can be “pushed” with a click of a mouse).[00103J The phrases “Application Program Interface” and API as are used herein mean a set of commands, functions and / or protocols that computer programmers can use when building software for a specific operating system. The API allows programmers to use predefined functions to interact with an operating system, instead of writing them from scratch. Common computer operating systems, including Windows, Unix, and the Mac OS, usually provide an API for programmers. An API is also used by hardware devices that run software programs. The API generally makes a programmer’s job easier, and it also benefits the end user since it generally ensures that all programs using the same API will have a similar user interface.

[0104] The phrase “central processing unit” as is used herein means a computer hardware component that executes individual commands of a computer software program. It reads program instructions from a main or secondary memory and then executes the instructions one at a time until the program ends. During execution, the program may display information to an output device such as a monitor.

[0105] The term “execute” as is used herein in connection with a computer, console, server system or the like means to run, use, operate or carry out an instruction, code, software, program and / or the like. Accordingly, a non-transitory computer-readable medium may store instructions that, when executed by one or more processors, cause the one or more processors to associate an asset with location data, manufacture data, and industry data. The location data may include a physical location of the asset. The one or more processors may be further caused to generate a predictive maintenance schedule for the asset based on the manufacture data and the industry data. The one or more processors may be further caused to adjust the predictive maintenance schedule based on the location data, and output at least a portion of the predictive maintenance schedule for display.

[0106] In this disclosure, the descriptions of the various embodiments have been presented for purposes of illustration and are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein. Thus, the appended claims should be construed broadly, to include other variants and embodiments, which may be made by those skilled in the art.

[0107] In some aspects, apparatuses, systems, and methods are provided according to one or more of the following examples:

[0108] Example 1: A system may include an application server to host an application program, and the application program may include one or more modules to associate an asset with location data, manufacture data, and industry data for input into the Al module. Location data may include a physical location of the asset. The system may further include an Al module communicably coupled to the one or more modules, and the Al module may receive the manufacture data, the user data, and the industry data from the one or more modules. The Al module may generate a predictive maintenance schedule for the asset based on the manufacture data and the industry data. The Al module may receive the location data from the one or more modules and adjust the predictive maintenance schedule based on the location data.

[0109] Example 2: A method may include associating an asset with location data, manufacture data, and industry data, and the location data may include a physical location of the asset. The method may further include generating a predictive maintenance schedule for the asset based on the manufacture data and the industry data. The method may further include adjusting the predictive maintenance schedule based on the location data and outputting at least a portion of the predictive maintenance schedule for display.

[0110] Example 3: A non-transitory computer-readable medium may store instructions that, when executed by one or more processors, cause the one or more processors to associate an asset with location data, manufacture data, and industry data. The location data may include a physical location of the asset. The one or more processors may be further caused to generate apredictive maintenance schedule for the asset based on the manufacture data and the industry data. The one or more processors may be further caused to adjust the predictive maintenance schedule based on the location data, and output at least a portion of the predictive maintenance schedule for display.

[0111] The following features may be incorporated into the various embodiments described above, such features incorporated either individually or in conjunction with one or more of the other features:

[0112] The one or more modules may associate the asset with user data for input to the Al module, and the Al module may receive user data from the one or more modules and adjust the predictive maintenance schedule based on the user data. The user data may include how often the asset is used. Generating the predictive maintenance schedule may include calculating a lifetime cost of the asset and creating maintenance events for the asset, based on industry data including warranty information of the asset, that minimizes the lifetime cost by maximizing warranty benefits. Generating the predictive maintenance schedule may include comparing industry data including asset failure patterns with the warranty information. Generating the predictive maintenance schedule may include calculating a lifetime cost of the asset, and adjusting the predictive maintenance schedule may include minimizing the lifetime cost of the asset based on the location data by moving the date of one or more maintenance events on the predictive maintenance schedule based on the location data. Generating the predictive maintenance schedule may include calculating a lifetime cost of the asset, and adjusting the predictive maintenance schedule may include minimizing the lifetime cost of the asset based on the user data by moving the date of one or more maintenance events on the predictive maintenance schedule based on the user data. Associating an asset with location data may include associating the location of a computing device, that scans a label affixed to the asset, at the time the label was scanned to the asset accordingly requiring no human input of location data. The one or more modules may receive manufacture data, including a model number of the asset and a serial number of the asset, based on the label. The Al module may analyze visual data of the asset captured during service of the asset in response to a maintenance event on the predictive maintenance schedule to verify service execution. The predictive maintenance schedule may be adjusted based on location data including weather data. Generating the predictive maintenance schedule may include calculating a lifetime cost of the asset and creating maintenance events for the asset, based on industry data includingwarranty information of the asset, that minimizes the lifetime cost by maximizing warranty benefits. Generating the predictive maintenance schedule may include calculating a lifetime cost of the asset, and adjusting the predictive maintenance schedule may include minimizing the lifetime cost of the asset based on the location data by moving the date of one or more maintenance events on the predictive maintenance schedule based on the location data. Associating an asset with location data may include associating the location of a computing device, that scans a label affixed to the asset, at the time the label was scanned to the asset accordingly requiring no human input of location data. The method may further include analyzing visual data of the asset captured during service of the asset in response to a maintenance event on the predictive maintenance schedule to verify service execution. Generating the predictive maintenance schedule may include calculating a lifetime cost of the asset and creating maintenance events for the asset, based on industry data including warranty information of the asset, that minimizes the lifetime cost by maximizing warranty benefits. Generating the predictive maintenance schedule may include calculating a lifetime cost of the asset, and adjusting the predictive maintenance schedule may include minimizing the lifetime cost of the asset based on the location data by moving the date of one or more maintenance events on the predictive maintenance schedule based on the location data. Associating an asset with location data may include associating the location of a computing device, that scans a label affixed to the asset, at the time the label was scanned to the asset accordingly requiring no human input of location data. The non-transitory computer-readable medium may further cause the one or more processors to analyze visual data of the asset captured during service of the asset in response to a maintenance event on the predictive maintenance schedule to verify service execution. The one or more modules may receive manufacture data, including a model number of the asset and a serial number of the asset, based on the label. The Al module may analyze visual data of the asset captured during service of the asset in response to a maintenance event on the predictive maintenance schedule to verify service execution. The predictive maintenance schedule may be adjusted based on location data including weather data. The Al module may autonomously schedule maintenance events based on the maintenance schedule. The system may include a communication module to transmit maintenance scheduling alerts to third-party service providers. The Al module may verify the identity of maintenance personnel based on time-stamped inputs and image recognition. The system may include a display module to generate a graphical user interface to show upcoming maintenance tasks. The Al modulemay operate in a closed loop configuration to restrict the source of input data to approved databases. The one or more processors may be further caused to prioritize maintenance actions based on cost-effectiveness. The one or more processors may be further caused to generate alerts based on deviations from manufacturer-recommended service intervals. The one or more processors may be further caused to output for display a service verification interface for third- party providers. The one or more processors may be further caused to restrict Al module input to verified databases and approved user inputs.

[0113] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and / or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments in this disclosure have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope of the embodiments as described herein. Numerous other modifications, equivalents, and alternatives will become apparent once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such modifications, equivalents, and alternatives where applicable.

Claims

CLAIMSWHAT IS CLAIMED IS:

1. A system comprising: an application server to host an application program, the application program comprising: one or more modules to associate an asset with location data, manufacture data, and industry data for input into an artificial intelligence (“Al”) module, wherein location data comprises a physical location of the asset; and an Al module communicably coupled to the one or more modules, the Al module to: receive the manufacture data, the user data, and the industry data from the one or more modules; generate a predictive maintenance schedule for the asset based on the manufacture data and the industry data; receive the location data from the one or more modules; and adjust the predictive maintenance schedule based on the location data.

2. The system of claim 1, the one or more modules to associate the asset with user data for input to the Al module, the Al module to receive user data from the one or more modules and adjust the predictive maintenance schedule based on the user data, wherein user data comprises how often the asset is used.

3. The system of claim 1, wherein generating the predictive maintenance schedule comprises calculating a lifetime cost of the asset and creating maintenance events for the asset, based on industry data comprising warranty information of the asset, that minimizes the lifetime cost by maximizing warranty benefits.

4. The system of claim 3, wherein generating the predictive maintenance schedule comprises comparing industry data comprising asset failure patterns with the warranty information.

5. The system of claim 1, wherein generating the predictive maintenance schedule comprises calculating a lifetime cost of the asset, and wherein adjusting the predictive maintenance schedule comprises minimizing the lifetime cost of the asset based on the location data by moving the date of one or more maintenance events on the predictive maintenance schedule based on the location data.

6. The system of claim 2, wherein generating the predictive maintenance schedule comprises calculating a lifetime cost of the asset, and wherein adjusting the predictive maintenance schedule comprises minimizing the lifetime cost of the asset based on the user data by moving the date of one or more maintenance events on the predictive maintenance schedule based on the user data.

7. The system of claim 1, wherein associating an asset with location data comprises associating the location of a computing device, that scans a label affixed to the asset, at the time the label was scanned to the asset accordingly requiring no human input of location data.

8. The system of claim 7, wherein the one or more modules receive manufacture data, comprising a model number of the asset and a serial number of the asset, based on the label.

9. The system of claim 1, the Al module to analyze visual data of the asset captured during service of the asset in response to a maintenance event on the predictive maintenance schedule to verify service execution.

10. The system of claim 1, wherein the predictive maintenance schedule is adjusted based on location data comprising weather data.

11. A method comprising: associating an asset with location data, manufacture data, and industry data, wherein location data comprises a physical location of the asset; generating a predictive maintenance schedule for the asset based on the manufacture data and the industry data;adjusting the predictive maintenance schedule based on the location data; and outputting at least a portion of the predictive maintenance schedule for display.

12. The method of claim 11, wherein generating the predictive maintenance schedule comprises calculating a lifetime cost of the asset and creating maintenance events for the asset, based on industry data comprising warranty information of the asset, that minimizes the lifetime cost by maximizing warranty benefits.13 The method of claim 11, wherein generating the predictive maintenance schedule comprises calculating a lifetime cost of the asset, and wherein adjusting the predictive maintenance schedule comprises minimizing the lifetime cost of the asset based on the location data by moving the date of one or more maintenance events on the predictive maintenance schedule based on the location data.

14. The method of claim 11, wherein associating an asset with location data comprises associating the location of a computing device, that scans a label affixed to the asset, at the time the label was scanned to the asset accordingly requiring no human input of location data.

15. The method of claim 11, further comprising analyzing visual data of the asset captured during service of the asset in response to a maintenance event on the predictive maintenance schedule to verify service execution.

16. A non-transitory computer-readable medium storing instructions that, when executed by one or more processors, cause the one or more processors to: associate an asset with location data, manufacture data, and industry data, wherein location data comprises a physical location of the asset; generate a predictive maintenance schedule for the asset based on the manufacture data and the industry data; adjust the predictive maintenance schedule based on the location data; and output at least a portion of the predictive maintenance schedule for display.

17. The non-transitory computer-readable medium of claim 16, wherein generating the predictive maintenance schedule comprises calculating a lifetime cost of the asset and creating maintenance events for the asset, based on industry data comprising warranty information of the asset, that minimizes the lifetime cost by maximizing warranty benefits.

18. The non-transitory computer-readable medium of claim 16, wherein generating the predictive maintenance schedule comprises calculating a lifetime cost of the asset, and wherein adjusting the predictive maintenance schedule comprises minimizing the lifetime cost of the asset based on the location data by moving the date of one or more maintenance events on the predictive maintenance schedule based on the location data.

19. The non-transitory computer-readable medium of claim 16, wherein associating an asset with location data comprises associating the location of a computing device, that scans a label affixed to the asset, at the time the label was scanned to the asset accordingly requiring no human input of location data.

20. The non-transitory computer-readable medium of claim 16, further causing the one or more processors to analyze visual data of the asset captured during service of the asset in response to a maintenance event on the predictive maintenance schedule to verify service execution.

Images