Anomaly detection and application management method and a system thereof

Abstract

The present disclosure discloses a technique for application management and anomaly detection Once a request for processing of an application is received, a set of parameters associated with the request is determined. Subsequently, a plurality of attributes associated with at least one service provider and service platform are analyzed. Further, the set of parameters associated with the request received at the service platform are perpetually correlated against the corresponding attributes to determine a success rate in the processing of at least one application. Determining one or more anomalies in the processing of at least one application if the success rate is detected below a threshold value and designating kill switch for at least one application or at least one service provider based on the detection of one or more anomalies and progressively launch the designated kill switch for the at least one application or the at least one service provider.

Description

FORM 2THE PATENTS ACT, 1970 (39 of 1970)&THE PATENTS RULES, 2003COMPLETE SPECIFICATION (See section 10, rule 13)“ANOMALY DETECTION AND APPLICATION MANAGEMENT METHOD AND A SYSTEM THEREOF”The following specification particularly describes the invention and the manner in which it is to be performed.TECHNICAL FIELD

[0001] This disclosure relates to anomaly detection in the processing of an application. More particularly, the present disclosure relates to a system and method for anomaly detection during the processing of the application and managing the execution of the application post-detection of anomalies.BACKGROUND

[0002] In today’s scenario, most of the applications are available on a single platform. Though at the customer or application provider’s end, it appears that the services are working smoothly and there is no challenge in managing the services. However, in real scenario, to ensure smooth service, the service platform has to manage a substantial volume of data and needs to apply various logic so that the customer experience may remain intact or get enhanced. For example, if a service platform provides support for various applications such as travel, insurance, gaming, merchant payments, recharges, and peer-to-peer payments, then they need to manage a high volume of data related to all of these applications.

[0003] Given the widespread adoption of payment applications, establishing customer trust and delivering a fast, seamless experience related to the processing of payments are some of the major challenges faced by service platforms supporting payment applications. Along with ensuring a smooth flow of money, the prevention of scenarios such as money getting stuck is one of the biggest challenges for payment applications. The reason is that any issue in the money movement can cause customer anxiety, adversely affecting customer confidence in the application. This, in turn, may also result in increased customer escalations and wastage of network resources in managing such activities.

[0004] Therefore, there is a need to provide a system and method that is capable of solving the above-mentioned problems and is efficient in terms of time and cost.

[0005] The information disclosed in this background of the disclosure section is only for enhancement of understanding of the general background of the disclosure and should not be takenas an acknowledgment or any form of suggestion that this information forms the prior art already known to a person skilled in the art.SUMMARY

[0006] In an embodiment, the present disclosure relates to an application management method. The method comprises receiving a request for processing of at least one application. The method further comprises determining a set of parameters associated with the request. Further, the method comprises analyzing a plurality of attributes associated with at least one service provider and the service platform based on the request received for processing of the at least one application. The method further comprises perpetually correlating the set of parameters associated with the request received at the service platform against the corresponding attributes of the plurality of attributes to determine a success rate in processing of the at least one application. Thereafter, the method comprises determining one or more anomalies in processing the at least one application if the success rate is detected below a threshold value. Further, the method comprises designating a kill switch for the at least one application or the at least one service provider based on the detection of the one or more anomalies and progressively managing launching of the designated kill switch for the at least one application or the at least one service provider.

[0007] In another embodiment, the present disclosure discloses an apparatus for application management. The apparatus comprises at least one processor and a memory unit coupled with the at least one processor. The at least one processor is configured to receive a request for processing of at least one application. The at least one processor is further configured to determine a set of parameters associated with the request. Further, the at least one processor is configured to analyze a plurality of attributes associated with at least one service provider and the service platform based on the request received for processing of the at least one application. The at least one processor is further configured to perpetually correlate the set of parameters associated with the request received at the service platform against the corresponding attributes of the plurality of attributes to determine a success rate in processing of the at least one application. Thereafter, the at least one processor is configured to determine one or more anomalies in processing the at least one application if the success rate is detected below a threshold value. Further, the at least one processor is configured to designate a kill switch for the at least one application or the at least oneservice provider based on the detection of the one or more anomalies and progressively manage launching of the designated kill switch for the at least one application or the at least one service provider.

[0008] The foregoing summary is illustrative only and is not intended to be in any way limiting. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features will become apparent by reference to the drawings and the following detailed description.BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS

[0009] The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the figures to reference features and components. Some embodiments of the system and / or methods by embodiments of the present subject matter are now described, by way of example only, and regarding the accompanying figures, in which:

[0010] Fig. 1 illustrates an environment for application management by a service platform, by some embodiments of the present disclosure;

[0011] Fig. 2 illustrates a detailed diagram of a system for application management, by some embodiments of the present disclosure;

[0012] Fig. 3 depicts application management by a personalized kill switch, by some embodiments of the present disclosure;

[0013] Fig.4 depicts a process flow diagram for application management and kill switch application, by some embodiments of the present disclosure;

[0014] Fig.5 depicts a flow chart of an exemplary method for application management, by some embodiments of the present disclosure;

[0015] It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative systems embodying the principles of the present subject matter. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudo code, and the like represent various processes that may be represented in a computer- readable medium and executed by a computer or processor, whether such computer or processor is explicitly shown.DESCRIPTION OF THE DISCLOSURE

[0016] In the present document, the word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any embodiment or implementation of the present subject matter described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments.

[0017] While the disclosure is susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawings and will be described in detail below. It should be understood, however, that it is not intended to limit the disclosure to the particular forms disclosed, but on the contrary, the disclosure is to cover all modifications, equivalents, and alternative falling within the spirit and the scope of the disclosure.

[0018] The terms “comprises”, “comprising”, or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a setup, device or method that comprises a list of components or steps does not include only those components or steps but may include other components or steps not expressly listed or inherent to such setup or device or method. In other words, one or more elements in a device or system or apparatus proceeded by “comprises... a” does not, without more constraints, preclude the existence of other elements or additional elements in the device, system, or apparatus.

[0019] The terms “includes”, “including”, or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a setup, device, or method that includes a list of components or steps does not include only those components or steps but may include other components or steps not expressly listed or inherent to such setup or device or method. In other words, one or more elements in a system or apparatus proceeded by “includes... a” does not, without more constraints, preclude the existence of other elements or additional elements in the system or method.

[0020] As used herein, the term “user device” may refer to one or more electronic devices that are configured to directly or indirectly communicate with or over one or more networks. A Mobile device or user device may be a mobile or portable computing device, a desktop computer, a laptop, a palmtop, a server, and / or the like. Furthermore, the term “computer” may refer to any computing device that includes the necessary components to receive, process, and output data, and normally includes a display, a processor, a memory, an input device, and a network interface. A “computing system” may include one or more computing devices or computers. An “interface” refers to a generated display, such as one or more graphical user interfaces (GUIs) with which a user / entity may interact, either directly or indirectly (e.g., through a keyboard, mouse, touchscreen, etc.).

[0021] As used herein, the term "processor" may refer to any suitable data computation device or devices. A processor may comprise one or more microprocessors working together to accomplish a desired function. As used herein, the term “processor” is not limited merely to those integrated circuits referred to in the art as a processor, but broadly refers to a microcontroller, a microcomputer, a programmable logic controller, an application-specific integrated circuit, and any other programmable circuit. In some embodiments, processor(s) may include specially designed hardware (e.g., application-specific integrated circuits (ASICs), electrically erasable programmable read-only memories (EEPROMs), field-programmable gate arrays (FPGAs), and the like) for controlling the operations of the computing device. The processor may include a Central Processing Unit (CPU) which comprises at least one high-speed data processor adequate to execute program components for executing user and / or system-generated requests.

[0022] As used herein, the term "memory" may be any suitable device or device that can store electronic data. A suitable memory may comprise a non-transitory computer-readable medium thatstores instructions that can be executed by a processor to implement a desired method. Examples of memories may comprise one or more memory chips, disk drives, etc. Such memories may operate using any suitable electrical, optical, and / or magnetic mode of operation. However, there are many different ways in which memory may be coupled to the system or processor. Memory blocks may be used for a variety of purposes such as, for example, caching and / or storing data, programming instructions, and the like.

[0023] As used herein, the application may be a service request raised by a user on a service platform. For example, the application and / or service request may be related to commercial or noncommercial activities such as financial services, education-related services, legal services, medical services, insurance, Hotel and Travel services, etc. The stated services are only examples and should not be construed as a limitation. A person skilled in the art may appreciate that the service platform may support multiple services at one instance and the services may also be updated on the service platform based on the requirement and / or on user request.

[0024] As used herein, the term “service provider" may refer to an entity, such as a company, an issuing bank, or a merchant, that enables the user to process the application. The service provider may be a single entity or group of entities that facilitate multiple services or applications.

[0025] The terms such as “entity”, “individual”, “business” or “user” are used interchangeably throughout the disclosure and should not be considered as a limitation.

[0026] The terms such as “service platform”, “application server”, “server” is used interchangeably throughout the disclosure and should not be considered a limitation

[0027] The terms such as “service”, “application” are used interchangeably throughout the disclosure and should not be considered a limitation

[0028] It will be apparent that systems and / or methods described herein can be implemented in different forms of hardware, software, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not limiting the implementations. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code, it being understood that softwareand hardware can be designed to implement the systems and / or methods based on the description herein.

[0029] As explained in the background section, the present disclosure mainly deals with the applications where payment applications are involved and focuses on ensuring smoother operations. The present disclosure mainly works on managing system load during times of outages or high traffic while improving the user experience. To ensure the efficient processing of service (e.g. operations or financial transactions), the present disclosure focuses on identifying the failures across channels that might go unnoticed. In addition, the disclosed technique ensures that the funds involved during the processing of the services available on the application do not stuck for either sender or receiver and that the user experience is maintained as smooth, fast, and secure.

[0030] In this regard, it is crucial to handle system load during instances of internal or external system slowdowns when users tend to retry the processing of the service on the application. This results in a significant surge in server requests, leading to more strain on an already degraded system and an increase in overall recovery time. Further, manual detection of failures in the system often occurs after an issue has been raised by customers or banks, leading to unnecessary delays in identifying the root cause. A person skilled in the art may understand that delayed detection of slowness or failures can significantly impact a large number of customers and backend systems (as the server load may increase due to multiple re-attempts), resulting in financial losses and decreased customer confidence.

[0031] Thus, the present disclosure provides a robust solution that is capable of detecting failures across systems in an automated timely manner both at global and granular levels. Additionally, to prevent customer money from getting stuck, the present disclosure provides a technique that may selectively notify customers about the issue so that they may not attempt such activities that may fail completely or partially. In other words, the system detects any potential failures early in the application processing and generates a notification for the users so that the user may not attempt the request and select another service or application. Alternatively, the system may provide an option for the user to select other payment options to complete the transaction. For example, in a situation where a customer has two service providers (service provider 1, Service provider 2) andservice provider 1 is facing any issue in providing the service to the user, then the system may provide alternate option to the user to select service provider! for processing the application / service. In another embodiment, the system may disable the service provider 1 and allow the user to avail the service from the service provider!. In this way, the chances of service or payment failure may be reduced. The same is explained in detail in upcoming paragraphs.

[0032] Fig. 1 illustrates an exemplary environment 100 for application management, in accordance with some embodiments of the present disclosure. The exemplary environment 100 depicts a service platform 102 on which a plurality of applications may be present and these applications may be accessed by one or more users i.e. user l, user ! user n. The same service platform 102 may be connected to various service providers. For the sake of brevity, only two service providers are considered in the environment, however, a person skilled in the art may appreciate that there may be a plurality of service providers associated with the service platform 102. The service providers may be banks, application providers, agents, etc. that are required for processing of the services / applications available at the service platform 102. Once a request for the application is received by the service platform 102, the service platform 102 may contact the service provider to provide the service to the user who has requested the service. The same may be understood with the help of an example. For example, the user_l has requested for mobile recharge application. In such a scenario, the service platform may provide the recharge service to the user_l with the help of the service provider, let's say service provider!. For this, the service platform may receive a request from the user_l through a network for processing at the service platform 102. In an exemplary embodiment, if user_l has selected the mode of payment as UPI then the service platform may check which service provider is selected by the user_l. For example, the user_l has an account associated with two service providers i.e., service providerl and service provider!. The service platform 102 on receiving the request for utilizing service providerl may determine a set of parameters associated with the request. The set of parameters associated with the request may be registration details of one or more users associated with the request and application-related details. The registration details include user identification, date of registration on the service platform, etc. The application details may include details like type of application, nature of application, service usage etc. Subsequent to receiving a request, the service platform 102 may transmit a service request to the service providerl to receive the attributes associated withthe service providerl. Once, the service platform has data including the set of parameters and plurality of attributes, the service platform 102 correlates the parameters and attributes and determines a success rate of processing the application. If the success rate associated with the processing of the application for service provider 1 is greater than a threshold (e.g. 90%) then the service platform may process the request generated by the user_l with the service providerl. In another scenario, if the service platform determines that the success rate of processing the request by the service providerl is below the threshold limit then it may further determine the anomalies in processing the request. Based on the determination of one or more anomalies, the service provider 102 identifies that there is more chance of failure of the request than success then the service platform 102 may apply the designated kill switch for the determined application and stop the request of processing the application through service providerl. In an alternate scenario, the service platform 102 may disable the request generation for service providerl in the particular application and may prompt or notify the user to select service provider 2 (as an alternate option) for processing the request for the same request. In this way, the user experience may not be affected, and the network resources may also be saved. It may be appreciated that the threshold for the application of a kill switch may be static or dynamic. In a case where there are less chances of performance variation concerning the load of application requests, time of the day etc., a static threshold is preferred, this threshold value may be fixed based on requirements to cater the processing of the applications whereas, if there are variations in respect of the performance of service providers or service platform then, a dynamic threshold may be considered. The dynamic threshold may be computed based on the machine learning model(s) or user-defined algorithm(s) e.g. turbulence algorithm. In an exemplary embodiment, the turbulence algorithm may comprise stages like pre-processing of input, histogram constructions, cluster formation, pruning, and threshold calculation. A person skilled in the art may appreciate that there may be other algorithms as well that may be utilized to provide a dynamic threshold to meet the service platform requirement.

[0033] Considering the scenario provided in Fig. 1, it is presented that the service platform 102 may keep on monitoring the attributes of the service providers i.e., service provider 1 and service provider2. The attributes may be transaction processing time, transaction type, request type, quantum of transactions, etc. Based on the analysis of the attributes related to the service providers in a predefined time (that may be set by the service platform or may be set by the service provider),the service platform 102 may determine whether a kill switch is required for the application provided by the service provider or not. Further, the quantum of the kill switch application may also depend on the mapping of attributes with the parameters of the request. In a scenario, the mapping of parameters with attributes is performed to evaluate a success rate, where the success rate is calculated based on the number of application requests received by the service platform and the number of applications successfully processed by the service providers or by the service platform in a predefined time. The predefined time may be a fixed time interval (e.g., 8:00 A.M- 8:30 AM, 9:00 PM-10:00 PM etc.) set by the service platform for computation of the success rate or it may be a time period computed based on the load analysis performed on real-time data or historical data available for applications available on service platform etc. Thus, a person skilled in the art may appreciate that the predefined time may be set based on the service platform’s requirement. As presented in an exemplary scenario considered in fig. 1, if the success rate is determined more than 90% then the service platform 102 may either not apply the kill switch (reference is made to service provider 1) or may remove the already applied kill switch ((reference is made to service provider2) for the application provided by the service provider whereas if the success rate of the processing of applications falls below a threshold (i.e., 90% in this case), then a kill switch is applied for the applications provided by the service provider. In the exemplary scenario, the service platform based on the attributes provided by the service provider 1 determines that the success rate of processing of the application is 80% (which is below the threshold limit i.e. 90%) then, the service provider may apply kill switch for X% of the applications provided by the service provider 1. Similarly, the service platform 102 has removed the kill switch for Z% applications when the success rate is achieved by 80% by the service provider 2. In another scenario, if the attributes related to service providerl indicate that the success rate has fallen further (i.e. to 70%) then the service platform 102 may increase the kill switch application by Y%. In this way, service provider 102 may progressively increase the kill switch application for service provider 1 if the success rate keeps on declining. In an alternate scenario, service platform 102 determines that the success rate is improving, based on the monitoring and determination of attributes associated with the service providers, service platform 102 may also remove the kill switch and may decrease the %age of application of the kill switch for the service provider (like for service provider 2, in the first instance, the kill switch was removed from Z% and then in the second instance, the kill switch is removed by X% and at last when the predetermined threshold isachieved then no kill switch is applied for service provider 2. The role and function of the service platform are explained in detail in Fig. 2.

[0034] The service platform 102 may be the same or similar to server 202 of Fig. 2 which interacts with the user device 204 and the service providers (not shown in this figure). The users User_l, User2,... .User n as mentioned in Fig. 1 may send a request for processing the application from their user devices. For the sake of brevity and ease of understanding, only one user device 204 is considered in Fig. 2. Skilled people may appreciate that there may be a plurality of user devices that may interact with the server 204. As stated earlier, the term “User device” may refer to one or more electronic devices that are configured to directly or indirectly communicate with the service platform / server 202 via one or more communication networks. In an exemplary embodiment, there may be a single service platform that may facilitate multiple applications. Further, a skilled person may appreciate that the user device may be a mobile or portable computing device, a desktop computer, a laptop, a palmtop, a server, and / or the like.

[0035] The user device 204 may comprise a processor, memory, user interface, etc. The users may utilize the user interface of the user device 204 to select the application for processing. Once the application is selected then the processor of the user device may instruct the transceiver of the user device to transmit the request to the service platform 202 to process the service request initiated by the user for a particular application. The user device 204 is connected to the service platform 202 via a communication network (not shown in the figure).

[0036] Further, the system of Fig. 2, may comprise an interface 206, memory 208, at least one processor 218, and Units 220 operatively and communicatively coupled to one another. It may be understood that system 200 may be accessed by multiple users through one or more user devices 204 or applications residing on the user devices. Examples of user devices may include, but are not limited to, an loT device, an loT gateway, a portable computer, a personal digital assistant, a handheld device, and a workstation, a mobile device. The user device is communicatively coupled to server 202 through a network (not shown in the figure).

[0037] In one implementation, the network may be a wireless network, a wired network, or a combination thereof. The network may be implemented as one of the diverse types of networks, such as intranet, local area network (LAN), wide area network (WAN), the internet, and the like. The network may either be a dedicated network or a shared network. The shared network represents an association of the diverse types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Hypertext Transfer Protocol Secure (HTTPS), Transmission Control Protocol / Internet Protocol (TCP / IP), Wireless Application Protocol (WAP), and the like, to communicate with one another. Further, the network may include a variety of network devices, including routers, bridges, servers, computing devices, storage devices, and the like.

[0038] Interface 206 may include a variety of software and hardware interfaces, for example, a web interface, a network interface, an Input / Output interface, a graphical user interface, and the like. The Input / Output (I / O) interface 206a may allow the server 202 to interact with the user through the user devices 204. For example, the user may interact with server 202 through GUI, audio input, text input, video input, or any combination thereof. Additionally, the I / O interface 206a may also receive an application request from the user device 204 that indicates the intention of a user to access / process an application. Apart from receiving the application processing request from the user device 204, I / O interface 206a may enable the server 202 to communicate with other computing devices, such as web servers, service providers, and external data servers (not shown). The I / O interface 206a may facilitate multiple communications within a wide variety of networks and protocol types, including wired networks, for example, LAN, cable, etc., and wireless networks, such as WLAN, cellular, or satellite. The I / O interface 206a may include one or more ports for connecting many devices or to another server. The network interface 206b may allow server 202 to interact with one or more databases / data sources either directly or via the network.

[0039] In one implementation, unit 220 may comprise transceiver 220a, determination unit 220b, detection unit 220c, application unit 220d, and other units (not shown in the figure). The other units may be used to perform other functions of the server 202 which are not described in the specification for the sake of brevity. According to embodiments of the present disclosure, these units 220a-220d may comprise hardware components like processors, microprocessors,microcontrollers, and application-specific integrated circuits for performing various operations of the server 202. In another embodiment, the units 220 may be software modules stored in the memory 208 which may be executed by at least one processor 218 for performing the operations of the server 202. It must be understood to a person skilled in the art that at least one processor 218 may also perform all the functions of units 220a-220d according to various embodiments of the present disclosure. For example, the at least one processor 218 of the service platform keeps on evaluating certain rules to calculate the success rate and accordingly applies the kill switch for the service platform or the service providers.

[0040] Memory 208 may store attribute information 210, Kill switch-related information 214, and other data 220. Further, the attributes information 210 comprises service providers’ information 212a, service platform information 212b, and application information 212c. Further, the kill switch 214 may be applied as general kill switch 214a, service provider-specific kill switch 214b, and application-specific kill switch 214c. Depending upon the detection of one or more anomalies, the service platform 202 may apply a general kill switch, service provider-specific kill switch, or application-specific kill switch. Memory 208 may also have an application database that may store information related to various applications facilitated by server 202. Further, Memory 208 may also have other data 220 as well that may include various temporary data and files generated by units 220.

[0041] The transceiver 220a receives a request for processing the application from the user device 204. Based on the type of application, the transceiver 220a requests the service platform 202 to provide access to the applications and process the application. There may be various applications installed on the user device which are associated with a common service platform. The transceiver of the user device may transmit the request for accessing the application to the transceiver 220a of the service platform / server 202. In an exemplary embodiment, the request may be related to insurance, travel, recharge, stock, games etc. Once the user device 204 transmits the request for processing the application, then the determination unit 220b may determine the attributes 210 related to service provider so that it may determine whether the processing of the application should be allowed or not.

[0042] The determination unit 210b may form a matrix based on the set of parameters related to the request received from the user device and the plurality of attributes related to the service platform, service provider, and applications. The plurality of attributes may be a service provider ID, application details, processing time of the application, number of applications currently served by the service provider, application-specific error, latency observed at service platform, etc. For example, the service provider-related attributes may include service provider ID, application processing success rate, application processing time, and type of error encountered in the processing of the application. The service platform-related attributes may involve network-related or data-related issues that may contribute to latencies. The application-related attributes may involve application-specific details such as application type e.g. application requiring high-speed data, normal speed data, the memory requirement for the application, etc.

[0043] Based on the attributes of one or more service providers and the service platform’s parameters, and request related parameters, the service platform 202 may form a matrix that is used by the detection unit 220c of the service platform 202 for the determination of the success rate for the applications processed by the service providers and / or the service platform 202.

[0044] It may be appreciated that there may be a single matrix for capturing the attributes related to the service platform and the service provider or there may be separate matrices formed for service providers and service platform attributes. In an exemplary embodiment, the first matrix includes latencies and failure rates of server APIs and resources. This matrix is designed to track the performance and usage of different components / factors involved at the service platform in the processing of the application. The second matrix involves performance -related attributes of the service providers such as the number of successful and failed action items per service provider, processing time per service provider, errors encountered etc. For the sake of brevity, the explanation is provided considering a single matrix for all the attributes related to service platform and service providers.

[0045] Also, this matrix may help in the determination of one or more anomalies associated with the Service platform 202 or service provider or application. In an exemplary embodiment, the matrix formed by the service platform 202 may comprise at least one of: the application success rate, processing time of an application, type of errors encountered while executing the application,number of applications initiated by the users for service platform, latencies observed at service platform, application related issue, etc. To understand the same, an exemplary scenario is considered where a bank may be considered as a service provider and PhonePE may be considered as a service platform and there may be a plurality of users associated with the service platform. The service platform, i.e. the PhonePE server may monitor one of the attributes as transaction success rate i.e. percentage of transactions that are successfully completed with no errors or issues reported, out of the total number of transactions attempted within a specified period of time. Similarly, the processing time attribute may be based on the processing time taken by the service provider to process the transaction successfully. The processing time refers to the time taken by the service provider to process and complete a transaction in a payment system or financial application. In other words, the processing time to complete a transaction span from the point where the transaction is initiated by the user to when it is completed. More time to complete a transaction may result in user dissatisfaction and may require launching of the kill switch. In this way, attribute information and set of parameters are used by the detection unit 220c in detecting one or more anomalies at the service provider end. An exemplary matrix is presented here below:

[0046] Based on the matrix, the detection unit 220c may detect the success rate for each of the plurality of service providers. Mainly, the attributes are used by the application management system that is integrated with the service platform 202 for one or more anomaly detection. Accordingly, the detection unit 220c of the service platform 202 may decide the necessity of the application of a kill switch. If the success rate falls below a threshold value, then the server 202 may launch a designated kill switch for the application provided by the service provider.Alternatively, if the success rate is above a threshold value, then there is no requirement to apply a kill switch. The same can be understood from the table below:Table 2

[0047] In Table 2, entry 1, the detection unit 220c determines that the success rate is 90%, considering the reference of Fig.1 , where the threshold is marked as 90% thus, the application unit 220d may not apply kill switch to the application provided by the service provider 1. However, if there is a fall in the success rate like in entries 2 and 3, then the service platform 202 may apply the kill switch to the applications provided by service providers 1 and 2 respectively.

[0048] Further, if there are multiple applications provided by the same service provider that are falling below the threshold limit then the service platform 202 may apply a general kill switch which is designated for that service provider. Further, a general kill switch may also be applied for periods where a service provider has already provided intimation about downfall or maintenance - related activities. In another scenario, if there is only a selected application for which the success rate is falling for different service providers then the service platform 202 may apply the application-specific kill switch. In yet another scenario, if there is a set of applications only that is provided by a specific service provider and the success rate for those set of applications is falling below the threshold value then the application unit may apply a kill switch specific to the service provider only. The set of applications may include one or more applications. The application unit 220d may progressively apply or remove the kill switch based on one or more anomalies detected. For example, if the success rate falls below the first threshold, then the application may apply kill switch on a set of applications. Further, if the success rate declines further then the application unitmay increase the application of the kill switch so that the user may not attempt to request that service where failure is quite predictable. Further, on the application of kill switch the application unit 220d may also provide notification to its user about the absence of the application or service provider so that the user may not attempt to request the same service in its absence period. This may also help in boosting the confidence of the user towards the service platform.

[0049] As Fig. 2 explains, the application of general kill switch, service-provider-specific kill switch, and / or application-specific kill switch, Fig. 3 depicts a personalized kill switch. Kill switch provides partial blocking capabilities and allows for specific percentages of applications / actions to be blocked. This addresses the use case of sending a subset of requests to the server when the system is running degraded but not completely down. For example, a bank's success rate typically remains above 80% and it declines to 70%, then the kill switch may be applied to only 10% of the transactions. During the next anomaly detection, if the success rate drops again below 70% (e.g., 50%), then the kill switch application may be considered for blocking 20% of the transactions and it continues to increase the percentage as it degrades further. Contrarily, if the service provider's overall performance improves, the kill switch application may be applied on a decreased percentage of actions and eventually the Kill switch feature is removed from all the actions / applications .

[0050] The Anomaly Detection and Kill switch application at the service platform may apply designated kill switches based on the user's pattern or registration date, to ensure a personalized and ideal experience for each user. For instance, if there is a success rate issue in the "check balance" or transaction process, the service provider may try to disable this process for new registered users so that their initial experience with the service platform 202 may not be negatively impacted. However, if the service platform 202 is not able to recover even after disabling the process / actions related to “check balance” for other users, only then the new registered users will be impacted.

[0051] Additionally, this concept may be extended to increase personalization for each user. The kill switch launching may vary based on factors such as the frequency of usage of the application or the risk involved. To understand this, an exemplary scenario may be considered. In an exemplary scenario, suppose the service platform 202 has determined to block 10% ofactions / applications, resulting in the need to select specific actions or users that should be blocked. The hash-based approach on user id (sender or receiver) is designed to achieve this goal. This approach can be extended to have a more custom selection of the impacted user base. Allowing applications / actions for newly registered users on the service platform, taking into account that most users likely registered with the intent of utilizing applications. If applications are prevented for these users, then this may impact the experience of the newly registered user, reducing the likelihood of them returning to use the application in the future. Maintaining consistency in this selection process for a Kill switch period is essential, meaning a particular user should experience the same behavior during the Kill switch period regarding whether an application / action is allowed or not.

[0052] Another criterion for selecting applications for blocking or allowing is based on the service providers. For example, during evenings when the volume of applications related to food is high, then the service platform 202 may allow the applications related to service providers who are in the food delivery business to proceed. The same may be understood by an exemplary scenario, however, the same may not be considered as a limitation. This specific criterion may vary depending on different periods, events, or peak user traffic and analysis of the volume of actions performed by the users.

[0053] Another criterion for the selection of actions and / or applications to allow or block may be the risk involved. To give more preference to high-risk associated action items when partial kill switches are applied. There are multiple other ways to identify and select applications or action items for personalization, same can be applied on the service platform based on the requirements.

[0054] Based on at least one of the above-mentioned criteria, the determination unit 220b in communication with the decision unit 220c may determine the applications or action items on the kill switch that may be applied and if the kill switch is applied then whether a partial or full kill switch is required to be applied. Accordingly, the application unit 220d may apply the kill switch for service provider, application or service platform.

[0055] A skilled person may also appreciate that there may be other criteria as well and those additional parameters or criteria may be taken into account on a need basis. In anotherembodiment, there may be a look-up table available in memory 208 where the criteria and %age of kill switch application are stored and based on the criteria that the success rate is meeting or falling above the threshold, kill switch may be launched for a particular service provider or application. The kill switch may be applied considering the registration date as well and the user experience on the service platform should be enhanced if there is a possibility available. If the application or service provider is not at all working, only in that scenario, the user experience of newly registered users may be impacted.

[0056] The service platform 202 may also take care of updating the kill switch application i.e. removing / increasing / decreasing based on the success rate achieved by the service provider for the listed application

[0057] Present disclosure also provides a provision that the service platform keeps on fetching the updated list of active kill switch available at its server end. Once, the user via the user device transmits an application processing request then the service platform evaluates the attributes and determines whether a kill switch is applied for the requested application or not. If the Kill switch is applied then it may block the processing of the application and transmit a notification or error message to the user otherwise, it may allow the processing of the application. The service platform may periodically synchronize the kill switches from the server to avoid a surge in the application processing requests, this leads to improved overall recovery time and performance of the system.

[0058] As used herein, the term ‘unit’ may refer to an Application Specific Integrated Circuit (ASIC), an electronic circuit, a hardware processor (shared, dedicated, or group) and memory that execute one or more software or firmware programs, a combinational logic circuit, and / or other suitable components that provide the described functionality. In an implementation, each of units 220a-220d may be configured as stand-alone hardware computing unit. In an embodiment, there may be other units as well and those may be used to perform various miscellaneous functionalities of the system 200. It will be appreciated that units 220 may be represented as a single unit or a combination of different units as well.

[0059] Figure 4 depicts a flow diagram of application management and kill switch application, in accordance with an embodiment of the present disclosure. In the flow diagram, the serviceplatform 402, a user device 404, and a service provider 406 are involved. In step 408, the user device 404 transmits a request for processing the application to the service platform 402. The server / service platform 402 at step 410, evaluates the parameters associated with the request such as user registration date, type or nature of the request, time of the request, risk involved etc. for processing the application.

[0060] At step 414, the service platform 402 may analyze the attributes that are received from the service provider 406 in step 412 a and from the service platform itself in step 412b. The attributes may comprise service provider ID, application details, processing time of the application, number of applications currently served by the service provider etc.

[0061] At step 416, the service provider based on the received attributes may form the matrix and evaluate a success rate for the application processing. If the success rate is achieved above a threshold, then at step 418, the service platform 402 may process the application for the user. Otherwise, based on parameters associated with the request and the attributes received from service provider 406 or service platform 402, service platform 402 may decide in steps 420 and 422 whether the kill switch should be applied for service provider 406 or service platform 402.

[0062] To understand the same, an exemplary scenario is presented. In an exemplary scenario, if for processing application ‘A,’ the service provider is taking very high processing time and a failure is encountered in processing of 50% of applications then, the service platform may apply a partial kill switch for the application so that only 50% volume of the application may reach to the service provider and those applications may result into a success. However, when only 50% applications are provided to the service provider, it is determined that the service provider is still failing to process the applications then the service platform may further increase the %age of kill switch application and may reduce the volume of applications to 40% by applying kill switch to 10% more applications. Gradually, the service provider may be able to meet the requirement or accordingly, kill switch is applied or removed from further applications. In this way, the processing time and resources both may be saved. Further, the user experience may also not be affected adversely.

[0063] Figure 5 illustrates an exemplary method for application management and kill switch application in real-time, in accordance with an embodiment of the present disclosure. The method 500 may also be described in the general context of computer-executable instructions. Computerexecutable instructions may include routines, programs, objects, components, data structures, procedures, modules, and functions, which perform specific functions or implement specific abstract data types.

[0064] The order in which method 500 is described is not intended to be construed as a limitation, and any number of the method blocks described may be combined in any order to implement the method. Additionally, individual blocks may be deleted from the methods without departing from the spirit and scope of the subject matter described.

[0065] At step 502, the method may include receiving a request for the processing of an application. The application request may be any service request shared with the service platform / application server to grant access to the particular application. The server may receive the request from the entity (i.e., an individual or business or a combination of both) via I / O interface for processing of the application.

[0066] At step 504, the at least one processor 218 may be configured to determine a set of parameters associated with the request. The set of parameters associated with the request comprises at least one of: registrations details of one or more users associated with the request (e.g., user ID, registration date etc.) and application related details (type or nature of application, volume of request received for particular application, error encountered in processing the application).

[0067] At step 506, the at least one processor 218 may be configured to analyze a plurality of attributes associated with at least one service provider and the service platform based on the request received for the processing of the at least one application. The plurality of attributes corresponds to at least one of: type of the at least one application, volume of requests for the at least one application, processing time taken by the at least one service provider to process the at least one application, type of error encountered in processing of the at least one application.

[0068] At step 508, the last one processor 218 is configured to perpetually correlate the set of parameters associated with the request received at the service platform against the corresponding attributes of the plurality of attributes to determine a success rate in processing of the at least one application.

[0069] At step 510, the at least one processor 218 is configured to determine one or more anomalies in processing the at least one application if the success rate is detected below a threshold value.

[0070] At step 512, at least one processor 218 is configured to designate a kill switch for the at least one application or the at least one service provider based on the detection of the one or more anomalies. A skilled person may appreciate that the kill switch may be applied as a general kill switch, service provider-specific kill switch and application- specific kill switch based on the requirements. The kill switch may be applied fully or partially as well.

[0071] At step 514, at least one processor 218 is configured to progressively launch the designated kill switch for the at least one application or the at least one service provider. When the kill switch is launched and is applied fully, it disables at least one application till the predefined time (say 2 mins). Then a notification is transmitted to one or more users that are associated with the application about the disabling of at least one application along with a reason. A skilled person may appreciate that the reason for the disabling of at least one application is based on the detection of one or more anomalies. At this moment, the service platform may provide at least one alternate option to the one or more users for processing the request received at the service platform. In an alternate scenario, the designated kill switch may be applied partially on the at least one application or the at least one service provider. In such scenario, the at least one processor 218 may selectively enable the at least one application for a set of users. The set of users may be the new users who have registered on the service platform recently or the users may be involved in high-risk data etc. There may be various options present on the service platform end select a particular set of users. Except on the set of users, at least one processor 218 may then disable at least one application for one or more users and transmit a notification to the one or more users about the disabling of at least one application along with a reason. The reason for the disabling of at least one applicationmay be based on one or more anomaly detection. Further, even in partially disabling the at least one application, the processor may provide an alternate option of processing the request received at the service platform to the one or more users. Once the anomalies are removed, then the at least one processor 218 may transmit another notification to the one or more users about enabling of at least one application.

[0072] It may also be appreciated that the proportion of application may increase or decrease based on the current success rate of processing of the application.

[0073] The terms "an embodiment", "embodiment", "embodiments", "the embodiment", "the embodiments", "one or more embodiments", "some embodiments", and "one embodiment" mean "one or more (but not all) embodiments of the invention(s)" unless expressly specified otherwise.

[0074] The terms "including", "comprising", “having” and variations thereof mean "including but not limited to", unless expressly specified otherwise.

[0075] The enumerated listing of items does not imply that any or all of the items are mutually exclusive, unless expressly specified otherwise. The terms "a", "an" and "the" mean "one or more", unless expressly specified otherwise.

[0076] A description of an embodiment with several components in communication with each other does not imply that all such components are required. On the contrary, a variety of optional components are described to illustrate the wide variety of embodiments of the invention.

[0077] When a single device or article is described herein, it will be readily apparent that more than one device / article (whether or not they cooperate) may be used in place of a single device / article. Similarly, where more than one device or article is described herein (whether or not they cooperate), it will be readily apparent that a single device / article may be used in place of the more than one device or article, or a different number of devices / articles may be used instead of the shown number of devices or programs. The functionality and / or the features of a device may be alternatively embodied by one or more other devices which are not explicitly described ashaving such functionality / features. Thus, other embodiments of the invention need not include the device itself.

[0078] The illustrated operations of Fig. 4-5 show certain events occurring in a certain order. In alternative embodiments, certain operations may be performed in a different order, modified, or removed. Moreover, steps may be added to the above-described logic and still conform to the embodiments described. Further, operations described herein may occur sequentially or certain operations may be processed in parallel. Yet further, operations may be performed by a single processing unit or by distributed processing units.

[0079] Finally, the language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the invention be limited not by this detailed description, but rather by any claims that issue on an application based here on. Accordingly, the disclosure of the embodiments of the invention is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.

[0080] While various aspects and embodiments have been disclosed herein, other aspects and embodiments will be apparent to those skilled in the art. The various aspects and embodiments disclosed herein are for purposes of illustration and are not intended to be limiting, with the true scope being indicated by the following claims.Referral Numerals:

Claims

We Claim:

1. An application management method comprising: receiving, at a service platform, a request for processing of at least one application; determining a set of parameters associated with the request; analyzing a plurality of attribute associated with at least one service provider and the service platform, based on the request received for processing of the at least one application; perpetually correlating the set of parameters associated with the request received at the service platform against the corresponding attribute of the plurality of attributes to determine a success rate in processing of the at least one application; determining one or more anomalies in processing the at least one application if the success rate is detected below a threshold value; designating a kill switch for the at least one application or the at least one service provider based on the detection of the one or more anomalies; and progressively launching the designated kill switch for the at least one application or the at least one service provider.

2. The method as claimed in claim 1 , wherein the set of parameters associated with the request comprises at least one of: registrations details of one or more users associated with the request and application related details.

3. The method as claimed in claim 1, wherein the plurality of attributes corresponds to at least one of: type of the at least one application, volume of requests for the at least one application, processing time taken by the at least one service provider to process the at least one application, type of error encountered in processing of the at least one application.

4. The method as claimed in claim 1, wherein the kill switch is designated from a group comprises of: general kill switch, service provider-specific kill switch and applicationspecific kill switch.

5. The method as claimed in claim 1, wherein the designated kill switch is applied fully on the at least one application or the at least one service provider.

6. The method as claimed in claim 5, further comprising: disabling the at least one application till the predefined time for which a kill switch is applied fully; and transmitting a notification to the one or more users about the disabling of the at least one application along with a reason, wherein the reason for the disabling of the at least one application is based on the one or more anomalies detection.

7. The method as claimed in claim 6, further comprising: providing at least one alternate option to the one or more users for processing the request received at the service platform.

8. The method as claimed in claim 1, wherein the designated kill switch is applied partially on the at least one application or the at least one service provider.

9. The method as claimed in claim 8, further comprising: selectively enabling the at least one application for a set of users when the designated kill switch is applied partially; disabling the at least one application for the one or more users except the set of users when the designated kill switch is applied partially; and transmitting a notification to the one or more users about the disabling of the at least one application along with a reason, wherein the reason for the disabling of the at least one application is based on the one or more anomalies detection.

10. The method as claimed in claim 6, further comprising: providing at least one alternate option to the one or more users for processing the request received at the service platform.

11. The method as claimed in claims 6 or 9, further comprising:transmitting another notification to the one or more users about enabling of the at least one application once the one or more anomalies are removed.

12. The method as claimed in claim 1, wherein the progressively launching of the designated kill switch further comprising: assigning a proportion of designated kill switch to at least one application or the at least one service provider if the one or more anomalies are determined to be present above a threshold value; perpetually determining the success rate associated with the processing of the at least one application; and gradually increasing the proportion of designated kill switch by a predefined amount if the monitored success rate is determined to be decreased.

13. The method as claimed in claim 1, wherein the progressively launching of the designated kill switch further comprising: assigning a proportion of designated kill switch to at least one application or the at least one service provider if the one or more anomalies are determined to be present above a threshold value; perpetually determining the success rate associated with the processing of the at least one application; and gradually decreasing the proportion of designated kill switch by a predefined amount if the monitored success rate is determined to be increased.

14. An application management apparatus integrated with a service platform, the apparatus comprises: a memory; and at least one processor coupled to the memory, wherein the at least one processor is configured to: receive a request for processing of at least one application; determine a set of parameters associated with the request;analyze a plurality of attributes associated with at least one service provider and the service platform, based on the request received for processing of the at least one application; perpetually correlate the set of parameters associated with the request received at the service platform against the corresponding attributes of the plurality of attributes to determine a success rate in processing of the at least one application; determine one or more anomalies in processing the at least one application if the success rate is detected below a threshold value; designate a kill switch for the at least one application or the at least one service provider based on the detection of the one or more anomalies; and progressive launch the designated kill switch for the at least one application or the at least one service provider.

15. The apparatus as claimed in claim 14, wherein the set of parameters associated with the request comprises at least one of: registrations details of one or more users associated with the request and application related details.

16. The apparatus as claimed in claim 14, wherein the plurality of attributes corresponds to at least one of: type of the at least one application, volume of requests for the at least one application, processing time taken by the at least one service provider to process the at least one application, type of error encountered in processing of the at least one application.

17. The apparatus as claimed in claim 14, wherein the kill switch is designated from a group comprises of: general kill switch, service provider-specific kill switch and applicationspecific kill switch.

18. The apparatus as claimed in claim 14, wherein the designated kill switch is applied fully on the at least one application or the at least one service provider.

19. The apparatus as claimed in claim 18, wherein the at least one processor is further configured to:disable the at least one application till the predefined time for which a kill switch is applied fully; and transmit a notification to the one or more users about the disabling of the at least one application along with a reason, wherein the reason for the disabling of the at least one application is based on the one or more anomalies detection.

20. The apparatus as claimed in claim 19, wherein the at least one processor is further configured to: provide at least one alternate option to the one or more users for processing the request received at the service platform.

21. The apparatus as claimed in claim 14, wherein the designated kill switch is applied partially on the at least one application or the at least one service provider.

22. The apparatus as claimed in claim 21, wherein the at least one processor is further configured to: selectively enable the at least one application for a set of users when the designated kill switch is applied partially; disable the at least one application for the one or more users except the set of users when the designated kill switch is applied partially; and transmit a notification to the one or more users about the disabling of the at least one application along with a reason, wherein the reason for the disabling of the at least one application is based on the one or more anomalies detection.

23. The apparatus as claimed in claim 19, wherein the at least one processor is further configured to: provide at least one alternate option to the one or more users for processing the request received at the service platform.

24. The apparatus as claimed in claims 19 or 22, wherein the at least one processor is further configured to: transmit another notification to the one or more users about enabling of the at least one application once the one or more anomalies are removed.

25. The apparatus as claimed in claim 14, wherein for the progressive launch of the designated kill switch, the at least one processor is further configured to: assign a proportion of designated kill switch to at least one application or the at least one service provider if the one or more anomalies are determined to be present above a threshold value; perpetually determine the success rate associated with the processing of the at least one application; and gradually increase the proportion of designated kill switch by a predefined amount if the monitored success rate is determined to be decreased.

26. The apparatus as claimed in claim 14, wherein for the progressive launch of the designated kill switch, the at least one processor is configured to: assign a proportion of designated kill switch to at least one application or the at least one service provider if the one or more anomalies are determined to be present above a threshold value; perpetually determine the success rate associated with the processing of the at least one application; and gradually decrease the proportion of designated kill switch by a predefined amount if the monitored success rate is determined to be increased.

Images