Claims:1. An Unmanned Vehicle (UV) 101, comprising:
a processing module 206 comprising a plurality of hardware processors; and
a memory module 205 comprising a plurality of instructions, said plurality of instructions causing at least one of the plurality of hardware processors to:
receive (302) at least one service request, by using an Input/Output (I/O) interface 201 of the UV 101;
identify (304) at least one service-bot 102 that is capable of handling the collected at least one service request, from a plurality of service-bots hosted aboard the UV, by processing the at least one service request using a service request processing module 202 of the UV 101;
deploy (306) the at least one service-bot 102 to a location specified in the at least one service request, by using a bot deployment module 203 of the UV 101;
coordinate (308) at least one action being performed by the at least one service-bot 102, while the at least one service-bot is providing at least one service as indicated in the at least one service request, at the specified location, by a coordination module 204 of the UV 101; and
collect (310) the at least one service-bot 102 when the at least one service-bot returns to the UV 101 after providing the at least one service at the specified location, by the bot deployment module 203.
2. The UV 101 as claimed in claim 1, wherein the UV 101 is in transit while receiving and processing the at least one service request.
3. The UV 101 as claimed in claim 1, wherein the service request processing module 202 identifies the at least one service-bot 102 from the plurality of service-bots, by:
identifying hardware and software requirements of the service as indicated in the at least one service request;
comparing the identified hardware and software requirements with a reference database stored in a memory module of the UV, wherein the reference database stores capability of the plurality of service-bots hosted aboard the UV in terms of hardware and software capabilities; and
identifying at least one service-bot which has capabilities matching the hardware and software requirements indicated in the at least one service request.
4. The UV 101 as claimed in claim 1, wherein the coordination module 204 is configured to coordinate at least one action being performed by the at least one service-bot 102, by interlinking with the at least one service-bot to perform at least one of real-time controlling, real-time monitoring, data transmission, and collaborative decision-making.
5. The UV 101 as claimed in claim 1, wherein the bot deployment module 203 prepares route plan for the one or more service-bots 102.
6. A processor implemented method for service management using an Unmanned Vehicle (UV) 101, comprising:
receiving (302) a service request from a user, via one or more hardware processors, by the UV 101;
processing the service request to identify one or more services being requested by the user, via one or more hardware processors, by the UV 101;
identifying (304) from a plurality of service-bots hosted aboard the UV, at least one service-bot that is capable of handling the collected at least one service request, via the one or more hardware processors, by the UV 101;
deploying (306) the at least one service-bot to a location specified in the at least one service request, by the UV 101;
coordinating (308) at least one action being performed by the at least one service-bot while the at least one service-bot is providing at least one service as indicated in the at least one service request, at the specified location, via one or more hardware processors, by the UV 101; and
collect (310) the at least one service-bot 102, when the at least one service-bot returns to the UV after providing the at least one service at the specified location, via one or more hardware processors, by the UV 101.
7. The method as claimed in claim 5, wherein identifying the at least one service-bot from a plurality of service-bots, comprises:
identifying hardware and software requirements of the service as indicated in the at least one service request;
comparing the identified hardware and software requirements with a reference database stored in a memory module of the UV, wherein the reference database stores capability of the plurality of service-bots hosted aboard the UV in terms of hardware and software capabilities; and
identifying at least one service-bot which has capabilities matching the hardware and software requirements indicated in the at least one service request.
8. The method as claimed in claim 5, wherein coordinating the at least one action comprises of interlinking with the at least one service-bot to perform at least one of real-time controlling, real-time monitoring, data transmission, and collaborative decision-making, by the UV.
9. The method as claimed in claim 5, wherein the UV prepares route plans for the one or more service-bots.
, Description:FORM 2

THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENT RULES, 2003

COMPLETE SPECIFICATION
(See Section 10 and Rule 13)

Title of invention:
METHOD AND SYSTEM FOR SERVICE MANAGEMENT USING UNMANNED VEHICLE (UV)

Applicant:
Tata Consultancy Services Limited
A company Incorporated in India under the Companies Act, 1956
Having address:
Nirmal Building, 9th Floor,
Nariman Point, Mumbai 400021,
Maharashtra, India

The following specification particularly describes the invention and the manner in which it is to be performed
TECHNICAL FIELD
[001] The disclosure herein generally relates to Unmanned Vehicles (UV), and, more particularly, to provide service management using a UV that hosts multiple service-bots on-board.

BACKGROUND
[002] Unmanned Vehicles (UV), such as ‘drones’, have gained immense popularity, and are being used in various applications/services. The term UV can also represent ground vehicles, water-borne vehicles, amphibious vehicles, and so on. For example, drones are used for applications such as but not limited to aerial imaging, mapping, change detection (for example, detecting change(s) occurred in a scene using image processing), parcel delivery, infrastructure inspection, public safety related applications, and so on.
[003] In a typical service eco-system wherein such UVs are used to provide services, a control center located somewhere on the ground receives service requests from users. The control center then assigns specific tasks as demanded by the service requests, to one or more UVs that are in service. The one or more UVs then move to appropriate destinations/locations, complete the task, and return to the control center or any other designated location.
[004] However, there are certain disadvantages associated with such an ecosystem. One disadvantage is that the UV mission starts upon receiving instruction from the control center, and the UV may take certain amount of time to reach the destination and some of these instructions could be repetitive. Certain applications, which are time-sensitive, may be affected due to the delay in the drone reaching the destination to provide the service. Another disadvantage that in the drone UV-system of the aforementioned type, the data processing happens at the control center or in the cloud and the control center sends mission instructions which control working of the UV. Such an implementation may have limitation in terms of ‘range’, which in turn limits service area of the UV and increases operational cost especially for repetitive services. In addition to this, any issue with the communication channel that connects the UV and the control center also can affect services of the UV.

SUMMARY
[005] Embodiments of the present disclosure present technological improvements as solutions to one or more of the above-mentioned technical problems recognized by the inventors in conventional systems. For example, in one embodiment, an Unmanned Vehicle (UV) is provided. The UV 101 includes a processing module 206 comprising a plurality of hardware processors; and a memory module 205 comprising a plurality of instructions. The plurality of instructions cause at least one of the plurality of hardware processors to receive (302) at least one service request, by using an Input/Output (I/O) interface 201 of the UV 101. The UV 101 then processes the at least one service request using a service request processing module 202, to identify (304) at least one service-bot 102 from a plurality of service-bots 102 hosted aboard the UV 101, that is capable of handling the collected at least one service request. Further the UV 101 deploys (306) the at least one service-bot 102 to a location specified in the at least one service request, by using a bot deployment module 203. The UV 101 also coordinates (308) at least one action being performed by the at least one service-bot 102, while the at least one service-bot 102 is providing at least one service as indicated in the at least one service request, at the specified location, by using a coordination module 204. Further, when the at least one service-bot 102 returns to the UV 101 after providing the at least one service at the specified location, the UV 101 collects (310) the service-bot 102 using the bot deployment module 203.
[006] In another aspect, a processor implemented method (300) for service management using an Unmanned Vehicle (UV) 101 is provided. In this method, the UV 101 receives (302) a service request from a user, via one or more hardware processors. The service request is processed to identify one or more services being requested by the user, via one or more hardware processors, by the UV 101. Further, from a plurality of service-bots 102 hosted aboard the UV 101, at least one service-bot that is capable of handling the collected at least one service request is identified (304), via one or more hardware processors, by the UV 101. The identified at least one service-bot 102 is then deployed (306) to a location specified in the at least one service request, by the UV 101. The UV 101 also coordinates (308) at least one action being performed by the at least one service-bot 102, while the at least one service-bot 102 is providing at least one service as indicated in the at least one service request, at the specified location, via one or more hardware processors. The UV 101 then collects (310) the at least one service-bot 102, when the at least one service-bot 102 returns to the UV 101 after providing the at least one service at the specified location, via one or more hardware processors.
[007] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

[008] 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:
[009] FIG. 1 illustrates an exemplary diagram depicting service request management using an Unmanned Vehicle (UV), according to some embodiments of the present disclosure.
[010] FIG. 2 is a functional block diagram depicting components of the UV of Fig. 1, according to some embodiments of the present disclosure.
[011] FIG. 3 is a flow diagram depicting steps involved in the process of managing service requests, using the UV of Fig. 1, in accordance with some embodiments of the present disclosure.
[012] FIGS. 4a and 4b illustrate is an example diagram depicting time savings achieved by using the UV for service management, in accordance with some embodiments of the present disclosure.

DETAILED DESCRIPTION OF EMBODIMENTS
[013] Exemplary embodiments are described with reference to the accompanying drawings. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. Wherever convenient, the same reference numbers are used throughout the drawings to refer to the same or like parts. While examples and features of disclosed principles are described herein, modifications, adaptations, and other implementations are possible without departing from the spirit and scope of the disclosed embodiments. It is intended that the following detailed description be considered as exemplary only, with the true scope and spirit being indicated by the following claims.
[014] Referring now to the drawings, and more particularly to FIG. 1 through FIG. 4, where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments and these embodiments are described in the context of the following exemplary system and/or method.
[015] FIG. 1 illustrates an exemplary diagram depicting service request management using an Unmanned Vehicle (UV), according to some embodiments of the present disclosure. The term Unmanned Vehicle (UV) can represent air-borne vehicles, ground vehicles, water-borne vehicles, amphibious vehicles, and so on. A user who intends to receive one or more of the services using the UV 100 can submit/place a request with a service center. In an embodiment, the user can submit the service request remotely, using any suitable medium such as but not limited to a web interface (a website), using an application on a smartphone, and so on. In another embodiment, the user may be physically present at the service center to submit the request using any provision on offer at the service center. Upon reception of request (and after completing all pre-requisites such as but not limited to user verification, payment processing, and so on), the service center transmits the request to the UV 101, using an appropriate communication medium established with the UV 101.
[016] The UV 101 receives the service request. The UV 101 hosts a plurality of service-bots 102 (102a. through 102.n) aboard, each one having specific hardware and software capabilities to handle/perform specific tasks associated with different services on offer. The UV 101 deploys one or more of the service-bots 102 to a location specified in the service request. While deploying the one or more service-bots 102, individual route plan for each of the service-bots 102 is prepared by the UV 101, by using appropriate technology such as but not limited to Artificial Intelligence (AI), and the route plans are assigned to corresponding service-bots. Upon reaching the destination, the deployed service-bots perform one or more tasks associated with the service being requested by the user. The UV 101 is in communication with the service-bots 102, and the UV 101 performs actions such as but not limited to control, monitoring, and data transmission associated with a collaborative decision making with respect to one or more of the tasks being performed by the deployed service-bots 102.
[017] After completing all the assigned tasks, the service-bots 102 return to the UV 101. The UV 101 can handle service requests from multiple users at a time, and can deploy service-bots to different locations to provide the requested services in parallel. The UV 101 can also handle communications and data processing with all the deployed service-bots 102, even though the service-bots 102 may be handling different tasks associated with different requested services. The UV 101 may also use appropriate scheduling mechanisms for the service request management purpose. In an embodiment, the UV 101 may process the incoming service requests in a first come first serve basis. In another embodiment, the UV 101 may prioritize certain service requests over others, based on type of service requested for. For example, requests associated with certain services such as ‘Medicare delivery’ may be classified as ‘critical’, and may be assigned top priority by the UV 101. In an embodiment, even though all the service-bots aboard may have been deployed to various locations while a ‘critical’ service request is received, the UV 101 can repurpose and redirect the service-bots 102 to location specified in the ‘critical’ service request to provide the service(s), and may later send service-bots to finish the previous (non-critical) service, when service-bots 102 (102a through 102.n) become available.
[018] In an embodiment, the UV 101 performs all the edge data processing, while service-bots 102 are in-transit, as well as deployment and retrieval of the service-bots 102. The UV 101 can be configured to change own location to match one or more criteria. For example, the UV 101 can select a position/location which is equidistant from all the deployed service-bots 102, so as to maintain communication with the service-bots 102. The UV 101 can be configured to monitor and report status of any service request, to the service center and in turn provide service outcome to the user, in real-time or at certain specific time intervals.
[019] FIG. 2 is a functional block diagram depicting components of the UV of Fig. 1, according to some embodiments of the present disclosure. The UV 101 includes an Input/Output (I/O) interface 201, a service request processing module 202, a bot deployment module 203, a coordination module 204, a memory module 205, a processing module 206, and a bot docking platform 207. The bot docking platform 207 further includes/hosts the plurality of service-bots 102.
[020] The I/O interface 201 is configured to provide at least one interface for the UV 101 to establish communication with at least one internal and/or external entity. For example, a communication channel supporting appropriate communication protocol is provided by the I/O interface 201 for the UV 101 to establish communication with the service center. The service requests may be collected by the UV 101, using this channel. The term ‘external entity’ may also refer to a user having appropriate rights/permissions, who can directly access one or more settings/configurations of the UV 101, using a suitable user interface provided by the I/O module 201. In another embodiment, the ‘external entity’ can refer to another UV. For example, when multiple UVs 102 are in-transit, they can communicate to each other and coordinate actions to perform one or more of the tasks to facilitate collaboration for service management. The term ‘internal entity’ in certain contexts may refer to one or more of the service-bots 102. For example, when one service-bot (say 102.a) is deployed to a particular location to serve a service request, the I/O interface 201 provides suitable communication channel for the UV 101 to establish, and to be in communication with the deployed service-bot 102.a. The I/O interface 201 can be further configured to provide appropriate channels for the other components of the UV 101 to establish communication with each other.
[021] The service request processing module 202 is configured to process the service request received at the I/O interface 201. By processing the service request, the service request processing module 202 extracts details pertaining to the one or more services requested, such as but not limited to type of service, location of service, duration, quantity of work, and so on. Based on one or more of the parameters extracted, and based on parameters such as but not limited to capabilities and number of service-bots 102 available on the bot docking platform 207, the service request processing module 202 decides and identifies one or more service-bots 102 that can be assigned the received service request. The service request processing module 202 prioritizes the requests arriving at the UV 101, based on parameters such as but not limited to type of service request, and criticality of the service request. The service request processing module 202 can be also configured to handle one or more service contingency plans to handle one or more unforeseen situations. For example, assume that a failure (for example mechanical, low battery, payload-camera issues etc.), occurs to one of the service-bots 102 (which may or may not be deployed at the instance of detection of the failure(s)). To make sure that this mechanical failure of the service-bot 102 does not affect service management, the service request processing module 202 can perform appropriate actions such as but not limited to load balancing, and prioritization and so on. The service request processing module 202 then provides information pertaining to the service requests, service-bots assigned for each service request, location, and scheduling details, as input to the bot deployment module 203.
[022] The bot deployment module 203 is configured to process information received from the service request processing module 202, and accordingly prepares a route plan for the service-bots 102, by using one or more appropriate technologies such as but not limited to Artificial Intelligence (AI). The bot deployment module 203 further handles all procedures with respect to deployment of one or more service-bots 102 from the bot docking platform 207, based on one or more of the details obtained from the service request processing module 202. The bot deployment module 203 is further configured to handle all processes so as to allow one or more of the service-bots 102 to return to the UV 101, after completing all tasks assigned.
[023] The coordination module 204 is configured to be in communication with the deployed service-bots 102, and perform data exchange and data processing associated with the one or more tasks being handled by each service-bot 102. By virtue of the communication with the service-bots 102, the coordination module 204 facilitates real-time control/monitor, data transmission and collaborative decision making.
[024] The memory module 205 can be configured to store any data associated with the service management being performed by the UV 101, permanently or temporarily. Depending on requirements, volatile and/or non-volatile storage spaces can be used for data storage. For example, a database storing details such as unique identification details, capabilities (hardware as well as software) can be stored in the memory module 205. Similarly, another database in which data pertaining to all service requests received over a period of time, and the corresponding actions taken by the UV 101 (such as but are not limited to inspection video/images/audio, retail - digital sign off/delivery status, inventory related etc.) can be maintained in the memory module 205. The memory module 205 can be further configured to provide access to the stored data, in response to an authorized request received.
[025] The processing module 206 can be configured to provide one or more hardware processors, which in turn perform data processing associated with one or more actions being performed by all components of the UV 101. The one or more hardware processors are configured to receive data processing requests from the other components of the UV 101, and in response, perform the data processing.
[026] The bot docking platform 207 is a docking platform aboard the UV 101. The bot docking platform 207 can host a certain number of service-bots 102. The bot docking platform 207 has physical capabilities to allow deployment and docking of the service-bots 102, while the UV 101 is still in transit. For example, when the UV 101 is an Unmanned Aerial Vehicle (UAV), the service-bots (which may be drones in this scenario) can take off and land on the bot docking platform 207.
[027] FIG. 3 is a flow diagram depicting steps involved in the process of managing service requests, using the UV of Fig. 1, in accordance with some embodiments of the present disclosure. The UV 101 receives (302) a service request from a user. In response to the request, based on the requirements specified by the service request, the UV 101 identifies (304) from a plurality of service-bots 102 onboard, one or more service-bots 102 that can handle the received service request. The service-bots may be compact drones that can perform certain specific tasks/activities.
[028] The identified one or more service-bots 102 are then deployed (306) to serve the service request, to one or more locations specified in the service request, from the UV 101, while the UV 101 is in transit. The one or more service-bots 102 perform (308) designated tasks/actions, after reaching the destination. The service-bots 102 are in communication with the UV 101 while in transit and while performing the tasks. The UV 101 also performs all the data-processing associated with the one or more tasks being handled by the service-bots 102, and sends appropriate commands/instructions to the service-bots 102. The one or more service-bots return to the UV 101, after finishing the tasks associated with the one or more services requested, and the UV 101 collects (310) the one or more service-bots 102 that are returning to the UV 101.
[029] In an embodiment, as all the data processing with respect to processing of service requests, route planning, control and coordination of service/tasks and so on is managed and performed within the UV 101 itself, upon receipt of the service request from the service center, the UV 101 can independently handle the service management, even when the service center is out of coverage area of the UV 101. In an alternate embodiment, the UV 101 can directly receive service requests from the users. Further, as the UV 101 stays closer to the service-bots (as compared to a stationary service center or data processing station) while the service-bots are performing tasks at a specified location, all the control signals/instructions with respect to the service management and the tasks reach the service-bots faster. At least because of the aforementioned reasons, there is time saving in the overall service management.
[030] FIGS. 4a and 4b are example diagrams that depict time savings achieved by using the UV 101 for service management, in accordance with some embodiments of the present disclosure. Fig. 4a depicts a typical scenario in which different service-bots 102 take off from a stationary pick up zone to provide service at various locations, in response to different service requests received. The table in Fig. 4a provides information pertaining to ‘distance covered, and transit time’ for each of the service-bots 102 in scenario 1. The scenario depicted in Fig. 4b matches the embodiments disclosed herein, in which a UV 101 carries multiple service-bots 102 and deploys the service-bots to provide service at different locations. Values provided indicate an improvement of the service management method and system disclosed herein, in terms of time savings. The table in Fig. 4b provides information pertaining to ‘distance covered, and transit time’ for each of the service-bots 102 in scenario 2. The values given in the tables of 4a and 4b indicate that time consumption (total transit time) and distance covered for each service-bot are less in scenario 2 as compared to that in scenario 1.
[031] The written description describes the subject matter herein to enable any person skilled in the art to make and use the embodiments. The scope of the subject matter embodiments is defined by the claims and may include other modifications that occur to those skilled in the art. Such other modifications are intended to be within the scope of the claims if they have similar elements that do not differ from the literal language of the claims or if they include equivalent elements with insubstantial differences from the literal language of the claims.
[032] The embodiments of present disclosure herein addresses unresolved problem of service management using Unmanned Vehicles (UV). The embodiment, thus provides a mechanism that allows a UV to host a plurality of service-bots aboard, and send one or more of the service-bots to perform specific tasks in response to a service request received from a user.
[033] It is to be understood that the scope of the protection is extended to such a program and in addition to a computer-readable means having a message therein; such computer-readable storage means contain program-code means for implementation of one or more steps of the method, when the program runs on a server or mobile device or any suitable programmable device. The hardware device can be any kind of device which can be programmed including e.g. any kind of computer like a server or a personal computer, or the like, or any combination thereof. The device may also include means which could be e.g. hardware means like e.g. an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a combination of hardware and software means, e.g. an ASIC and an FPGA, or at least one microprocessor and at least one memory with software modules located therein. Thus, the means can include both hardware means and software means. The method embodiments described herein could be implemented in hardware and software. The device may also include software means. Alternatively, the embodiments may be implemented on different hardware devices, e.g. using a plurality of CPUs.
[034] The embodiments herein can comprise hardware and software elements. The embodiments that are implemented in software include but are not limited to, firmware, resident software, microcode, etc. The functions performed by various modules described herein may be implemented in other modules or combinations of other modules. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can comprise, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
[035] The illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments. Also, the words “comprising,” “having,” “containing,” and “including,” and other similar forms are intended to be equivalent in meaning and be open ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items, or meant to be limited to only the listed item or items. It must also be noted that as used herein and in the appended claims, the singular forms “a,” “an,” and “the” include plural references unless the context clearly dictates otherwise.
[036] Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present disclosure. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term “computer-readable medium” should be understood to include tangible items and exclude carrier waves and transient signals, i.e., be non-transitory. Examples include random access memory (RAM), read-only memory (ROM), volatile memory, nonvolatile memory, hard drives, CD ROMs, DVDs, flash drives, disks, and any other known physical storage media.
[037] It is intended that the disclosure and examples be considered as exemplary only, with a true scope and spirit of disclosed embodiments being indicated by the following claims.