FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENT RULES, 2003
COMPLETE SPECIFICATION (See Section 10 and Rule 13)
Title of invention:
METHODS AND SYSTEMS FOR AUTOMATED PREPARATION OF BID PROPOSAL AND MANAGEMENT
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
Preamble to the description:
The following specification particularly describes the invention and the
manner in which it is to be performed.

CROSS-REFERENCE TO RELATED APPLICATIONS AND PRIORITY
[001] The present application claims priority from Indian provisional application no. 202121000977, filed on January 08, 2021. The entire contents of the aforementioned application are incorporated herein by reference.
TECHNICAL FIELD [002] The disclosure herein generally relates to the field of financial tools, and, more particularly, to methods and systems for automated preparation of a bid proposal and management for a new tender document.
BACKGROUND
[003] Organizations especially from manufacturing sector (herein after referred as tender receivers that receive tender documents) tend to respond a tender document such as request for proposal (RFP), request for quote (RFQ) issued by tender issuers to expand the business. The tender document includes a tender document information related to a project with various requirements defined by the tender issuers. The tender receivers typically review the requirements present in the tender document carefully and respond to the tender issuers in the form of a bid proposal in timely and accurately manner.
[004] Preparation of the bid proposal for the tender document, is a very challenging and exhaustive process which involves reviewing and understanding of the requirements present in the tender document, checking a feasibility criteria before going for the bid proposal, querying deviations, estimating timelines and bidding costs, preparing the bid proposal within stringent timelines, and so on. Also, the preparation of the bid proposal involves certain checkpoints, wherein decisions are to be taken by various stakeholders present in multiple departments of the tender receivers, before submitting the bid proposal for the tender document to the tender issuers.
[005] Conventional techniques in the art for the preparation of the bid proposal are mostly manual processes, and lack of standardization process due to unstructured format of tender documents. The manual preparation of the bid

proposal in response to the tender document usually time consuming and error prone. Further, the manual preparation of the bid proposal requires human invention at every stage, as multiple departments of the tender receivers may work together to prepare the bid proposal iteratively. A typical tender document may contain few hundreds of pages to thousands of pages and may come in various formats such as Portable Document Format (PDF), images such as JPEG and so on. In the manual preparation of the bid proposal, humans need to manually extract relevant information from the tender document for analysis to understand the requirements, check feasibility criteria, and to make decisions by engaging with various departments before preparing the bid proposal. Hence humans may tend to miss important requirements information present in the tender document, due to limited capabilities, which may lead to inaccurate bid proposal. The inaccurate bid proposal results in either: (i) unsuccessful bid (losing the bid) or (ii) additional financial burden especially in case of enhancement in the bid amount, even with the successful bid (winning the bid), both may lead to business loss for the tender receivers and may adversely affect the reputation of the organization.
[006] As the standardization process is not available and many stake holders are involved for the preparation of the bid proposal, automation for the preparation of the bid proposal is a challenge. Some attempts have been made in the art to automate the bid proposal preparation using machine learning and artificial intelligence techniques, but they limit to certain steps and hardly attempt to provide an end-to-end technique for the preparation of the bid proposal.
SUMMARY
[007] 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.
[008] In an aspect, a processor-implemented method for automated preparation of a bid proposal and management is provided. The method including the steps of: receiving by a tender receiver, a tender document, from a tender issuer, for which the bid proposal to be prepared, wherein the tender document comprises

at least one or more requirements defined by the tender issuer; extracting one or more key attributes, from the tender document, using a human reading mimicking technique and a domain ontology, wherein the one or more key attributes are associated with the at least one or more requirements; initiating a first check point to check whether (i) the one or more key attributes are feasible, or (ii) the one or more key attributes are infeasible, based on one or more feasibility rules in a predefined feasibility criteria; extracting one or more common key attributes and one or more department wise key attributes, from the tender document, using the human reading mimicking technique and the domain ontology, if the one or more key attributes are feasible at the first check point, wherein the one or more common key attributes and the one or more department wise key attributes are associated with the at least one or more requirements; performing a deviations check criteria to check one of: (i) one or more deviations are present in the tender document, (ii) the one or more deviations are absent in the tender document, based on the one or more common key attributes and the one or more department wise key attributes, and to receive clarifications from a tender issuer, if the one or more deviations are present in the tender document; initiating a second check point to check whether (i) the one or more common key attributes and the one or more department wise key attributes are feasible, or (ii) the one or more common key attributes and the one or more department wise key attributes are infeasible, based on (i) the clarifications, if the one or more deviations are present in the tender document, and (ii) the one or more feasibility rules in the predefined feasibility criteria; identifying a closest historical tender document for the tender document, using a trained closest tender document identification model, if the one or more common key attributes and the one or more department wise key attributes are feasible at the second check point; automatically preparing the bid proposal for the tender document, using one of: (i) the closest historical tender document and a bid value present in an associated bid proposal corresponding to the closest historical tender document, if the closest historical tender document for the tender document is identified, and (ii) the one or more key attributes of the tender document, if the closest historical tender document for the tender document is not identified, using a rule based natural language

generation (NLG) technique; receiving commercials and bills of materials, from the tender receiver; updating the bid proposal prepared for the tender document, with the commercials and bills of materials, to obtain a final bid proposal; submitting the final bid proposal corresponding to the tender document, to the tender issuer; and storing the tender document and the final bid proposal corresponding to the tender document, in a historical repository.
[009] In another aspect, a system for automated preparation of a bid proposal and management is provided. The system includes: a memory storing instructions; one or more Input/Output (I/O) interfaces; and one or more hardware processors coupled to the memory via the one or more I/O interfaces, wherein the one or more hardware processors are configured by the instructions to: receive, by a tender receiver, a tender document, from a tender issuer, for which the bid proposal to be prepared wherein the tender document comprises at least one or more requirements defined by the tender issuer; extract one or more key attributes, from the tender document, using a human reading mimicking technique and a domain ontology, wherein the one or more key attributes are associated with the at least one or more requirements; initiate a first check point to check whether (i) the one or more key attributes are feasible, or (ii) the one or more key attributes are infeasible, based on one or more feasibility rules in a predefined feasibility criteria; extract one or more common key attributes and one or more department wise key attributes, from the tender document, using the human reading mimicking technique and the domain ontology, if the one or more key attributes are feasible at the first check point, wherein the one or more common key attributes and the one or more department wise key attributes are associated with the at least one or more requirements; perform a deviations check criteria to check one of: (i) one or more deviations are present in the tender document, (ii) the one or more deviations are absent in the tender document, based on the one or more common key attributes and the one or more department wise key attributes, and to receive clarifications from a tender issuer, if the one or more deviations are present in the tender document; initiate a second check point to check whether (i) the one or more common key attributes and the one or more department wise key attributes are

feasible, or (ii) the one or more common key attributes and the one or more department wise key attributes are infeasible, based on (i) the clarifications, if the one or more deviations are present in the tender document, and (ii) the one or more feasibility rules in the predefined feasibility criteria; identify a closest historical tender document for the tender document, using a trained closest tender document identification model, if the one or more common key attributes and the one or more department wise key attributes are feasible at the second check point; automatically prepare the bid proposal for the tender document, using one of: (i) the closest historical tender document and a bid value present in an associated bid proposal corresponding to the closest historical tender document, if the closest historical tender document for the tender document is identified, and (ii) the one or more key attributes of the tender document, if the closest historical tender document for the tender document is not identified, using a rule based natural language generation (NLG) technique; receive commercials and bills of materials, from the tender receiver; update the bid proposal prepared for the tender document, with the commercials and bills of materials, to obtain a final bid proposal; submit the final bid proposal corresponding to the tender document, to the tender issuer; and store the tender document and the final bid proposal corresponding to the tender document, in a historical repository.
[010] In yet another aspect, there is provided a computer program product comprising a non-transitory computer readable medium having a computer readable program embodied therein, wherein the computer readable program, when executed on a computing device, causes the computing device to: receive, by a tender receiver, a tender document, from a tender issuer, for which the bid proposal to be prepared wherein the tender document comprises at least one or more requirements defined by the tender issuer; extract one or more key attributes, from the tender document, using a human reading mimicking technique and a domain ontology, wherein the one or more key attributes are associated with the at least one or more requirements; initiate a first check point to check whether (i) the one or more key attributes are feasible, or (ii) the one or more key attributes are infeasible, based on one or more feasibility rules in a predefined feasibility criteria; extract one or more

common key attributes and one or more department wise key attributes, from the tender document, using the human reading mimicking technique and the domain ontology, if the one or more key attributes are feasible at the first check point, wherein the one or more common key attributes and the one or more department wise key attributes are associated with the at least one or more requirements; perform a deviations check criteria to check one of: (i) one or more deviations are present in the tender document, (ii) the one or more deviations are absent in the tender document, based on the one or more common key attributes and the one or more department wise key attributes, and to receive clarifications from a tender issuer, if the one or more deviations are present in the tender document; initiate a second check point to check whether (i) the one or more common key attributes and the one or more department wise key attributes are feasible, or (ii) the one or more common key attributes and the one or more department wise key attributes are infeasible, based on (i) the clarifications, if the one or more deviations are present in the tender document, and (ii) the one or more feasibility rules in the predefined feasibility criteria; identify a closest historical tender document for the tender document, using a trained closest tender document identification model, if the one or more common key attributes and the one or more department wise key attributes are feasible at the second check point; automatically prepare the bid proposal for the tender document, using one of: (i) the closest historical tender document and a bid value present in an associated bid proposal corresponding to the closest historical tender document, if the closest historical tender document for the tender document is identified, and (ii) the one or more key attributes of the tender document, if the closest historical tender document for the tender document is not identified, using a rule based natural language generation (NLG) technique; receive commercials and bills of materials, from the tender receiver; update the bid proposal prepared for the tender document, with the commercials and bills of materials, to obtain a final bid proposal; submit the final bid proposal corresponding to the tender document, to the tender issuer; and store the tender document and the final bid proposal corresponding to the tender document, in a historical repository.

[011] In an embodiment, the one or more key attributes, from the tender document, are extracted, using the human reading mimicking technique and the domain ontology, by: identifying one or more contents, from the tender document, using a document extraction technique; extracting a plurality of keywords from each content of the one or more contents, using the human reading mimicking technique; and extracting the one or more key attributes from the plurality of keywords, using the domain ontology.
[012] In an embodiment, the one or more common key attributes and one or more department wise key attributes, from the tender document, are extracted, using the human reading mimicking technique and the domain ontology, if the one or more key attributes are is feasible at the first check point, by: identifying one or more contents, from the tender document, using a document extraction technique; extracting a plurality of keywords from each content of the one or more contents, using the human reading mimicking technique; and extracting the one or more common key attributes and the one or more department wise key attributes, from the plurality of keywords, using the domain ontology.
[013] In an embodiment, the trained closest tender document identification model, is obtained by: receiving a plurality of historical tender documents, from a historical repository; extracting (i) the one or more key attributes, (ii) the one or more common key attributes, and (iii) the one or more department wise key attributes, for each historical tender document of the plurality of historical tender documents, using the human reading mimicking technique and the domain ontology; generating a key attribute weight for each key attribute of the one or more key attributes, a common key attribute weight for each common key attribute of the one or more common key attributes, and a department wise key attribute weight for each department wise key attribute of the one or more department wise key attributes, for each historical tender document of the plurality of historical tender documents, using a natural language tool; calculating a total key attribute weight for each historical tender document of the plurality of historical tender documents, by adding the key attribute weight for each key attribute of the one or more key attributes, the common key attribute weight for each common key attribute of the

one or more common key attributes, and the department wise key attribute weight for each department wise key attribute of the one or more department wise key attributes; and training a long short-term memory based network with (i) the one or more key attributes, the one or more common key attributes, and the one or more department wise key attributes, and (ii) the total key attribute weight, for each historical tender document of the plurality of historical tender documents, to obtain the trained closest tender document identification model, by: passing the one or more key attributes, the one or more common key attributes, and the one or more department wise key attributes, for each historical tender document, to the long short-term memory based network, to obtain a predicted key attribute weight for each key attribute of the one or more key attributes, a predicted common key attribute weight for each common key attribute of the one or more common key attributes, and a predicted department wise key attribute weight for each department wise key attribute of the one or more department wise key attributes, for each historical tender document; calculating a total predicted key attribute weight for each historical tender document, by adding the predicted key attribute weight for each key attribute of the one or more key attributes, the predicted common key attribute weight for each common key attribute of the one or more common key attributes, and the predicted department wise key attribute weight for each department wise key attribute of the one or more department wise key attributes; optimizing an objective function that minimizes an error between (i) the total predicted key attribute weight for each historical tender document, and (ii) the total key attribute weight for each historical tender document; and updating model weights of the long short-term memory based network, based on the objective function.
[014] In an embodiment, the one or more key attributes for each historical tender document of the plurality of historical tender documents, are extracted, using the human reading mimicking technique and the domain ontology, by: identifying one or more contents, from each historical tender document, using a document extraction technique; extracting a plurality of keywords from each content of the one or more contents identified from each historical tender document, using the

human reading mimicking technique; and extracting the one or more key attributes from the plurality of keywords, for each historical tender document, using the domain ontology.
[015] In an embodiment, the one or extract the one or more common key attributes and the one or more department wise key attributes, for each historical tender document of the plurality of historical tender documents, are extracted, using the human reading mimicking technique and the domain ontology, by: identifying one or more contents, from each historical tender document, using a document extraction technique; extracting a plurality of keywords from each content of the one or more contents identified for each historical tender document, using the human reading mimicking technique; and extracting the one or more common key attributes and the one or more department wise key attributes, from the plurality of keywords, for each historical tender document, using the domain ontology.
[016] In an embodiment, the bid proposal for the tender document, is automatically prepared, based on the closest historical tender document and the bid value present in the associated bid proposal corresponding to the closest historical tender document, if the closest historical tender document for the tender document is identified, using the rule based natural language generation (NLG) technique, by: identifying (i) one or more tender parameters and associated tender parameter values, and (ii) one or more non-tender parameters and associated non-tender parameter values, from the closest historical tender document identified for the tender document; and automatically preparing the bid proposal for the tender document, based on (i) the one or more tender parameters and the associated tender parameter values, (ii) the one or more non-tender parameters and the associated non-tender parameter values, and (iii) the bid value associated with the closest historical tender document, using the rule based natural language generation (NLG) technique.
[017] In an embodiment, the bid proposal for the tender document, is automatically prepared based on the one or more key attributes of the tender document, if the closest historical tender document for the tender document is not identified, using the rule based natural language generation (NLG) technique, by:

identifying one or more tender parameters and associated tender parameter values, from the one or more key attributes of the tender document; generating one or more non-tender parameters and associated non-tender parameter values for the one or more non-tender parameters; calculating a bid value for the tender document, based on (i) the one or more tender parameters and the associated tender parameter values and (ii) the one or more non-tender parameters and the associated non-tender parameter value; and automatically preparing the bid proposal for the tender document, based on (i) the one or more tender parameters and the associated tender parameter values, (ii) the one or more non-tender parameters and the associated non-tender parameter values, and (iii) the bid value generated for the tender document, using the rule based natural language generation (NLG) technique.
[018] In an embodiment, the closest historical tender document for the tender document, is identified using the trained closest tender document identification model, if the one or more common key attributes and the one or more department wise key attributes are feasible at the second check point, by: passing the one or more key attributes, the one or more common key attributes and the one or more department wise key attributes, corresponding to (i) the tender document and (ii) each historical tender document of a plurality of historical tender documents, to the trained closest tender document identification model, to obtain a total predicted key attribute weight for the tender document and each historical tender document, respectively; finding one or more historical tender documents out of the plurality of historical tender documents, having the total predicted key attribute weight more than a predefined key attribute weight, if the total predicted key attribute weight for the tender document is greater than the predefined key attribute weight; calculating a distance metric between (i) the new tender document and (ii) each historical tender document of the one or more historical tender documents; and identifying the historical tender document among the one or more historical tender documents, having a least distance metric, as the closest historical tender document for the tender document.

[019] 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
[020] 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:
[021] FIG. 1 is an exemplary block diagram of a system for automated preparation of a bid proposal and management, in accordance with some embodiments of the present disclosure.
[022] FIG. 2A and FIG. 2B illustrates exemplary flow diagrams of a processor-implemented method for automated preparation of the bid proposal and management, in accordance with some embodiments of the present disclosure.
[023] FIG. 3 is a flowchart describing a process for calculating a distance metric to identify the closest historical tender document for the tender document, in accordance with some embodiments of the present disclosure.
DETAILED DESCRIPTION OF EMBODIMENTS [024] 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 scope of the disclosed embodiments.
[025] Automation for the preparation of the bid proposal is a challenge as a standardization process is not available and many stake holders to be involved for the preparation of a bid proposal for a tender document. Some attempts have been made in the art to automate the bid proposal preparation using machine learning

and artificial intelligence techniques, but they limit to certain steps and hardly attempt to provide an end-to-end technique for the preparation of the bid proposal.
[026] The present disclosure herein provides methods and systems for automated preparation of a bid proposal and management, that addresses the technical problems with the automated process. The present disclosure makes use of domain ontology for extracting relevant information from the tender document, and makes use of machine learning or deep learning techniques for identifying a closest bid proposal submitted in the past, and further make use of natural language generation (NLG) techniques for preparing the bid proposal automatically from end-to-end.
[027] In the context of the present disclosure, the term ‘organization’ refers to any industry including but is not limited to, construction industry, civil industry, production or manufacturing industry, information technology (IT) industry, banking industry, educational institution, and so on. The term ‘tender issuer’ refers to the organization that issues tenders (in the form of tender documents) and seeks bid proposals for the same from one or more tender receivers. The bid proposal includes a bid amount after evaluating certain feasibility criteria against the tender document. The term ‘tender receiver’ refers to the organization that receives the tender from the tender issuer and submits the bid proposal for the tender to the tender issuer.
[028] Referring now to the drawings, and more particularly to FIG. 1 through FIG. 3, 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 systems and/or methods.
[029] FIG. 1 is an exemplary block diagram of a system 100 for automated preparation of a bid proposal and management, in accordance with some embodiments of the present disclosure. In an embodiment, the system 100 includes or is otherwise in communication with one or more hardware processors 104, communication interface device(s) or input/output (I/O) interface(s) 106, and one or more data storage devices or memory 102 operatively coupled to the one or more

hardware processors 104. The one or more hardware processors 104, the memory 102, and the I/O interface(s) 106 may be coupled to a system bus 108 or a similar mechanism.
[030] The I/O interface(s) 106 may include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, and the like. The I/O interface(s) 106 may include a variety of software and hardware interfaces, for example, interfaces for peripheral device(s), such as a keyboard, a mouse, an external memory, a plurality of sensor devices, a printer and the like. Further, the I/O interface(s) 106 may enable the system 100 to communicate with other devices, such as web servers and external databases.
[031] The I/O interface(s) 106 can facilitate multiple communications within a wide variety of networks and protocol types, including wired networks, for example, local area network (LAN), cable, etc., and wireless networks, such as Wireless LAN (WLAN), cellular, or satellite. For the purpose, the I/O interface(s) 106 may include one or more ports for connecting a number of computing systems with one another or to another server computer. Further, the I/O interface(s) 106 may include one or more ports for connecting a number of devices to one another or to another server.
[032] The one or more hardware processors 104 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the one or more hardware processors 104 are configured to fetch and execute computer-readable instructions stored in the memory 102. In the context of the present disclosure, the expressions ‘processors’ and ‘hardware processors’ may be used interchangeably. In an embodiment, the system 100 can be implemented in a variety of computing systems, such as laptop computers, portable computers, notebooks, hand-held devices, workstations, mainframe computers, servers, a network cloud and the like.
[033] The memory 102 may include any computer-readable medium known in the art including, for example, volatile memory, such as static random

access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. In an embodiment, the memory 102 includes a plurality of modules 102a and a repository 102b for storing data processed, received, and generated by one or more of the plurality of modules 102a. The plurality of modules 102a may include routines, programs, objects, components, data structures, and so on, which perform particular tasks or implement particular abstract data types.
[034] The plurality of modules 102a may include programs or computer-readable instructions or coded instructions that supplement applications or functions performed by the system 100. The plurality of modules 102a may also be used as, signal processor(s), state machine(s), logic circuitries, and/or any other device or component that manipulates signals based on operational instructions. Further, the plurality of modules 102a can be used by hardware, by computer-readable instructions executed by the one or more hardware processors 104, or by a combination thereof. In an embodiment, the plurality of modules 102a can include various sub-modules (not shown in FIG. 1). Further, the memory 102 may include information pertaining to input(s)/output(s) of each step performed by the processor(s) 104 of the system 100 and methods of the present disclosure.
[035] The repository 102b may include a database or a data engine. Further, the repository 102b amongst other things, may serve as a database or includes a plurality of databases for storing the data that is processed, received, or generated as a result of the execution of the plurality of modules 102a. Although the repository 102a is shown internal to the system 100, it will be noted that, in alternate embodiments, the repository 102b can also be implemented external to the system 100, where the repository 102b may be stored within an external database (not shown in FIG. 1) communicatively coupled to the system 100. The data contained within such external database may be periodically updated. For example, data may be added into the external database and/or existing data may be modified and/or non-useful data may be deleted from the external database. In one example, the data may be stored in an external system, such as a Lightweight Directory

Access Protocol (LDAP) directory and a Relational Database Management System (RDBMS). In another embodiment, the data stored in the repository 102b may be distributed between the system 100 and the external database.
[036] Referring to FIG. 2A and FIG. 2B, components and functionalities of the system 100 are described in accordance with an example embodiment of the present disclosure. For example, FIG. 2A and FIG. 2B illustrates exemplary flow diagrams of a processor-implemented method 200 for automated preparation of the bid proposal and management, in accordance with some embodiments of the present disclosure. Although steps of the method 200 including process steps, method steps, techniques or the like may be described in a sequential order, such processes, methods and techniques may be configured to work in alternate orders. In other words, any sequence or order of steps that may be described does not necessarily indicate a requirement that the steps be performed in that order. The steps of processes described herein may be performed in any practical order. Further, some steps may be performed simultaneously, or some steps may be performed alone or independently.
[037] At step 202 of the method 200, the one or more hardware processors 104 of the system 100 are configured to receive a tender document by a tender receiver sent from the tender issuer. The bid proposal along with the bid value has to be prepared automatically by the tender receiver against the tender document. The tender document may be associated with a project and includes at least one or more requirements defined by the tender issuer.
[038] The tender document may be a new tender document or a present tender document for which the bid proposal to be prepared. The tender document may be received in the form of a request for proposal (RFP), a request for quote (RFQ) or any business proposal. The one or more requirements are considered to be essential components which defines the scope of the project defined by the tender issuer. In case of the manufacturing organization, the one or more requirements of the tender issuer typically include requisition of certain component or different components, or a product, in certain quantity (quantities). For example, the one or more requirements of the tender issuer may be requisition of 100 turbine machines,

the requisition of 1000 rotor assemblies suitable for making the turbine machines, where each rotor assembly should have 100 blades, and so on. The one or more requirements may also include technical specifications of each component or a product, such as physical parameters, chemical parameters, operating parameters, performance or efficiency parameters, and so on. For example, in case of the turbine machine, the physical parameters include occupation area of the turbine machine, weight of the turbine machine, size of the turbine machine, and so on. Similarly, the chemical parameters include a type material used for making the turbine machine, a melting point of the material, and so on. The operating parameters include a maximum operating speed of the turbine machine, power input and output levels to be maintained, and so on. The performance or efficiency parameters includes efficiency or yield of the turbine machine, maintenance, and durability of the turbine machine, and so on. The terms and conditions may include the timelines to meet by the bidding organization. Further, the one or more requirements may also include one or more terms and conditions including timelines.
[039] Apart from the one or more requirements, the tender document contains additional information including but are not limited to information related to the tender issuer, scope of the work, objective of the work, address of the tender issuer, and so on.
[040] The tender receiver is expected to submit the bid proposal (in the form of bid proposal document), in response to the tender document, within the specified timelines. The bid proposal document may typically include the bid amount, timelines and any other information that is to be proposed to the tender issuer. The bid amount represents a price or an expenses to complete the project and to meet the one or more requirements made by the tender issuer.
[041] The tender document may contain few hundreds of pages to thousands of pages and may not be in the standard structure, and every tender issuer (organization) may follow different structure and format for making the tender document. Typical formats of the tender document include PDF Portable Document Format (PDF), images such as JPEG, and so on.

[042] At step 204 of the method 200, the one or more hardware processors 104 of the system 100 are configured to extract one or more attributes from the tender document. The one or more key attributes are associated with the at least one or more requirements present in the tender document. In other words, the one or more key attributes are the attributes that are very essential to make a decision for going ahead or not to submit the bid proposal to the tender issuer. Each attribute of the one or more attributes includes at least a parameter keyword and a value keyword corresponding to the parameter keyword. Before extracting the one or more attributes from the tender document, the tender document may be converted into a plain text tender document. In an embodiment, a plain text extractor may be used to convert the tender document into the plain text tender document.
[043] In an embodiment, the plain text extractor may be a PDF extractor if the received tender document is in the PDF format. In another embodiment, the plain text extractor may be an image text extractor if the received tender document is in the image format. If the received tender document is in the PDF format, and if the received tender document includes one or more tables, one or more images, and one or more graphs, then the PDF extractor extracts the text from the one or more tables, the one or more images, and the one or more graphs as well.
[044] The one or more key attributes from the tender document, are extracted by using a human reading mimicking technique and a domain ontology. Firstly, one or more contents from the tender document are extracted using a document extraction techniques. The one or more contents may be one or more paragraphs, one or more sentences, one or more words, or a combination thereof, that are present in the tender document. The document extraction technique may utilize a text extraction tool from documents.
[045] Next, a plurality of keywords from each content of the one or more contents, are extracted using the human reading mimicking technique. The human reading mimicking technique converts each content of the one or more contents into one or more sentences and the one or more sentences into 1-gram, 2-gram and so on n-grams word combinations to extract a plurality of keywords from each content, in the form of keyword features, using a natural language processing. Lastly, the

one or more key attributes from the plurality of keywords are extracted using the domain ontology. In an embodiment the domain ontology includes a list of domain keywords and the relation or association between the list of keywords, in the form of keyword dictionaries and glossaries. For example, the domain ontology may be created using a domain knowledge of certain component making, specification of the component, capabilities of the organization, and so on. The one or more keywords out of the plurality of keywords extracted from each content, those matches with the list of domain keywords present in the domain ontology are identified as the one or more key attributes.
[046] Table 1 shows an exemplary list of key attributes (parameter keywords and corresponding value keywords) extracted from an exemplary tender document related to civil/constructional industry/organization, with the project named ‘Power and water plant project’.

Parameter keyword for each attribute Value keyword for each parameter keyword
Specification Number 327101-C-BOD-0001, Rev.00
Structural design software and version STAAD Pro V8i
Structural design life 30 years
Basic wind speed 45 m/sec
Topography factor 1.0 kzt
Importance factor - for wind calculations 1.15
Exposure Category C kz
Wind Directionality factor 0.85 kd
Seismic Category 2A
period of basic wind speed
Steel Pipes
Steel Tubing
Plates, Flats, Ordinary steel washers
bolt connection type bearing type
Heavy Hexagonal Nuts astm a563m.
Ta ble 1

[047] At step 206 of the method 200, the one or more hardware processors 104 of the system 100 are configured to initiate a first check point to check whether the one or more key attributes extracted at step 206 of the method are feasible or infeasible. One or more feasibility rules in a predefined feasibility criteria are used to check whether the one or more key attributes are feasible or infeasible, and to provide recommendations. The one or more feasibility rules may be associated with the one or more requirements of the tender issuer, and the related terms and conditions including the timelines to complete the project. In an embodiment, the one or more feasibility rules in the predefined feasibility criteria may be defined by the tender receiver based on capacity, resources, and possibility of the organization.
[048] More specifically, the one or more feasibility rules are framed based on one or more of: technical specification of the component or a product present in the tender document, timelines, resources of the tender receiver to fulfill the one or more requirements of the tender issuer, and so on. In an embodiment, the one or more feasibility rules may be present in the feasibility rules engine which may be stored in the repository 102b of the system 100.
[049] The first check point helps in generating the recommendations for taking the decision from one of: (i) go for the bid proposal preparation if the one or more key attributes (project in broad) are feasible, and (ii) no-go for the bid proposal preparation if the one or more key attributes (project in broad) are infeasible.
[050] In an embodiment, each key attribute of the one or more key attributes are matched with each feasibility rule of the one more feasibility rules at the first check point, to check the feasibility. Further, the first check point helps in identifying feasible key attributes and infeasible key attributes from the one or more key attributes obtained at step 208 of the method 200. If the one or more key attributes are infeasible, then the preparation of bid proposal is terminated and provide an alert to the tender receiver to not to ahead with the bid for the tender document received at step 202 of the method 200.
[051] At step 208 of the method 200, the one or more hardware processors 104 of the system 100 are configured to extract one or more common key attributes and one or more department wise key attributes, from the tender document, if the

one or more key attributes are feasible at the first check point checked at step 206 of the method 200. The one or more common key attributes and the one or more department wise key attributes are associated with the at least one or more requirements. The one or more department wise key attributes includes the one or more key attributes associated with each department of the plurality of departments associated with the tender receiver (organization). For example, in case of manufacturing industry, the plurality of departments includes, material procurement department, electrical department, finance department, legal department, core production department, and so on. The one or more common key attributes includes the one or more key attributes that are common to the plurality of departments associated with the tender receiver (organization).
[052] The one or more common key attributes and the one or more department wise key attributes, from the tender document are extracted using the human reading mimicking technique and the domain ontology, in the similar manner as mentioned at step 204 of the method 200. Firstly, one or more contents from the tender document are extracted using the document extraction techniques. The one or more contents may be one or more paragraphs, one or more sentences, one or more words, or the combination thereof, that are present in the tender document. The document extraction technique may utilize the text extraction tool from documents. Next, the plurality of keywords from each content of the one or more contents, are extracted using the human reading mimicking technique.
[053] Lastly, the one or more common key attributes and the one or more department wise key attributes are extracted from the plurality of keywords using the domain ontology. The list of domain keywords present in the domain ontology are classified into department wise domain keyword for each department of the plurality of departments and common domain keywords, using a pre-trained semi-supervised machine learning model. In an embodiment, the pre-trained semi-supervised machine learning model uses a clustering algorithm and a classification algorithm. The clustering algorithm may be an unsupervised clustering algorithm, which creates the keywords in the form of clusters. These clusters are filtered by domain experts to refine the keywords in each cluster. Refined keywords are used

as training classes for classifying the keywords present in the domain ontology, using the classification algorithm which is a supervised learning algorithm. Classified keywords are filtered again by the domain experts to create final common keyword classes and department wise keywords classes. The one or more keywords out of the plurality of keywords extracted from each content, those matches with the list of domain keywords having the relevant class are identified as at least of (i) a common key attribute, (ii) a department wise key attribute, and (iii) both the common key attribute and the department wise key attribute, to obtain the one or more common key attributes and the one or more department wise key attributes.
[054] Table 2 shows an exemplary list of common key attributes and department wise key attributes extracted from the exemplary tender document related to civil/constructional industry/organization, with the project named ‘Power and water plant project’, as mentioned in table 1.

Department wise Key attribute Common Key attribute
Manufacturing department key attributes Electric Cable
Specification Number+A5:A23 Electric Switches
Design load calculation method Electric Cable Type
Specification Number
Design load calculation method
Basic wind speed
period of basic wind speed
Topography factor
Exposure Category
Steel pipes
Steel tubing
Civil construction department key attributes
Structural design software and version
Structural design life
Importance factor - for wind calculations
Wind Directionality factor

Table 2
[055] At step 210 of the method 200, the one or more hardware processors 104 of the system 100 are configured to perform a deviations check criteria to check if one or more deviations present in the tender document, based on the one or more common key attributes and the one or more department wise key attributes. In an embodiment, the one or more deviations includes any important missing information, some information lacking clarity, some information is infeasible, and so on.
[056] The one or more deviations are checked by each department of the tender receiver (organization) based on the one or more department wise key attributes. For example, in case of requisition of 100 turbine machines, if the number of blades to be present in the rotor assembly is not specified, core material to be used is not clear, dimensions of the rotor assembly is not specified, or if the timelines to complete the project is very less than a normal production time of 100 turbine machines, and so on.
[057] If one or more deviations present in the tender document, then such one or more deviations are sent to the tender issuer by the tender receiver, to receive clarifications for the deviations, from the tender issuer.
[058] At step 212 of the method 200, the one or more hardware processors 104 of the system 100 are configured to initiate a second check point to check whether the one or more common key attributes and the one or more department wise key attributes are feasible or infeasible. The clarifications received at step 210 of the method 200 if the one or more deviations present in the tender document, the one or more feasibility rules in the predefined feasibility criteria specified at step 206 of the method 200 are further used to check whether the one or more common key attributes and the one or more department wise key attributes are feasible or infeasible.
[059] The second check point helps in further generating the recommendations for taking the decision from one of: (i) go for bid proposal document, if the one or more common key attributes and the one or more department wise key attributes are feasible, and (ii) no-go for bid proposal

preparation, if the one or more common key attributes and the one or more department wise key attributes are infeasible.
[060] In an embodiment, each attribute from the one or more department wise attributes and the one or more common attributes, is matched with each feasibility rule of the one more feasibility rules, at the second check point. If the one or more common key attributes and the one or more department wise key attributes are infeasible, then the preparation of bid proposal is terminated and the alert is provided further to the tender receiver to not to go ahead with the bid proposal for the tender document received at step 202 of the method 200.
[061] At step 214 of the method 200, the one or more hardware processors 104 of the system 100 are configured to identify a closest historical tender document for the tender document, if the one or more common key attributes and the one or more department wise key attributes are feasible at the second check point mentioned at step 212 of the method 200. The closest historical tender document is the tender document that may be received in the past from the same tender issuer or a different tender issuer. In an embodiment, the closest historical tender document may be identified for the tender document using a trained closest tender document identification model. In an embodiment, the trained closest tender document identification model may be a long short-term memory (LSTM) based network.
[062] The trained closest tender document identification model is obtained by training the LSTM based network with a plurality of historical tender documents. Obtaining the trained closest tender document identification model is further explained. The plurality of historical tender documents along with corresponding bid proposals, that are stored in a historical repository are received. In an embodiment, the historical repository may be stored in the repository 102b of the system 100.
[063] In an embodiment, each historical tender document and corresponding bid proposal may be received in the past from the same tender issuer mentioned at step 202 of the method 200 or a different tender issuer. Further, each

historical tender document of the plurality of historical tender documents may be associated with the successful bid proposals.
[064] Next, the one or more key attributes, the one or more common key attributes, and the one or more department wise key attributes, for each historical tender document of the plurality of historical tender documents, are extracted. The one or more key attributes, the one or more common key attributes, and the one or more department wise key attributes are extracted using the human reading mimicking technique and the domain ontology, as mentioned at step 204 of the method 200 and at the step 208 of the method 200, respectively. In this process, the one or more contents are identified from each historical tender document, using the document extraction technique. The plurality of keywords from each content of the one or more contents identified are extracted from each historical tender document, using the human reading mimicking technique. Then, the one or more key attributes, the one or more common key attributes, and the one or more department wise key attributes, are extracted, from the plurality of keywords, for each historical tender document, using the domain ontology.
[065] Next, a key attribute weight for each key attribute of the one or more key attributes, a common key attribute weight for each common key attribute of the one or more common key attributes, and a department wise key attribute weight for each department wise key attribute of the more department wise key attributes, is generated for each historical tender document of the plurality of historical tender documents. A natural language tool having a tool kit is used which generates weight for each key attribute type.
[066] Further, a total key attribute weight for each historical tender document of the plurality of historical tender documents, is calculated by adding the key attribute weight for each key attribute of the one or more key attributes, the common key attribute weight for each common key attribute of the one or more common key attributes, and the department wise key attribute weight for each department wise key attribute of the more department wise key attributes. Then, LSTM network is trained with (i) the one or more key attributes, the one or more common key attributes, and the one or more department wise key attributes, and (ii)

the total key attribute weight, for each historical tender document of the plurality of historical tender documents to obtain the trained closest tender document identification model.
[067] The training process to obtain the trained closest tender document identification model is further explained in the below steps. Initially, the LSTM based network is initialized with model weights before the training process. Next, the one or more key attributes, the one or more common key attributes, and the one or more department wise key attributes, for each historical tender document, are passed to the LSTM based network, to obtain a predicted key attribute weight for each key attribute of the one or more key attributes, a predicted common key attribute weight for each common key attribute of the one or more common key attributes, and a predicted department wise key attribute weight for each department wise key attribute of the more department wise key attributes, for each historical tender document.
[068] Next, a total predicted key attribute weight for each historical tender document, is calculated by adding the predicted key attribute weight for each key attribute of the one or more key attributes, the predicted common key attribute weight for each common key attribute of the one or more common key attributes, and the predicted department wise key attribute weight for each department wise key attribute of the more department wise key attributes. An objective function is optimized that minimizes an error between (i) the total predicted key attribute weight for each historical tender document, and (ii) the total key attribute weight for each historical tender document. Lastly, the model weights of the LSTM based network are updated based on the objective function. The trained closest tender document identification model is obtained once the training process for the plurality of historical tender documents is completed.
[069] The trained closest tender document identification model is then used to identify the closest historical tender document for the tender document. In this process, the one or more key attributes, the one or more common key attributes and the one or more department wise key attributes, corresponding to the tender document is passed to the trained closest tender document identification model, to

obtain a total predicted key attribute weight for the tender document. Then, the one or more key attributes, the one or more common key attributes and the one or more department wise key attributes, corresponding to each historical tender document of the plurality of historical tender documents, are passed to the trained closest tender document identification model, to obtain the total predicted key attribute weight for each historical tender document.
[070] Further, if the total predicted key attribute weight for the tender document is greater than a predefined key attribute weight, then one or more historical tender documents out of the plurality of historical tender documents, are found where each historical tender document of the one or more historical tender documents having the total predicted key attribute weight more than the predefined key attribute weight. The predefined key attribute weight is a threshold that is used to filter the historical documents that are best fit for the tender document for further comparative analysis.
[071] If the total predicted key attribute weight for the tender document is less than or equal to the predefined key attribute weight, then no historical document out of the plurality of historical documents is the best fit for the tender document and the identification process of the closest historical tender document for the tender document is aborted in this case.
[072] Then, a distance metric between (i) the tender document and (ii) each historical tender document of the one or more historical tender documents, is calculated. FIG. 3 is a flowchart describing a process for calculating a distance metric to identify the closest historical tender document for the tender document, in accordance with some embodiments of the present disclosure. As shown in FIG. 3, the distance metric between (i) the tender document and (ii) each historical tender document, is calculated by using a Bi-LSTM based network, based on the one or more key attributes, the one or more common key attributes and the one or more department wise key attributes, corresponding to the tender document and each historical tender document.
[073] The Bi-LSTM based network includes two LSTM cells where first LSTM cell is mirror image of the second LSTM cell. The first LSTM cell takes (i)

the one or more key attributes and (ii) the one or more department wise key attributes and the one or more common key attributes, of the tender documents as input, and the second LSTM cell takes (i) the one or more historical key attributes and (ii) the one or more historical department wise attributes and the one or more historical common attributes, of each historical tender document of the one or more historical tender documents as an input, and calculate the distance between (i) the tender document and (ii) each historical tender document.
[074] In an embodiment, the distance metric may be a Manhattan distance metric which calculates the distance between two documents based on the keywords present in each document. Lastly, one historical tender document out of the one or more historical tender documents, having the least distance metric, is identified as the closest historical tender document for the tender document. If two or more historical tender documents having the same least distance metric is identified, then any one such historical tender document is considered as the closest historical tender document for the tender document. In an embodiment, a Siamese network with LSTM and either a cosine similarity metric, textrank metric, or pagerank metric is used in the place of Bi-LSTM based network with the Manhattan distance metric, to calculate the distance metric between the tender document and each historical tender document.
[075] At step 216 of the method 200, the one or more hardware processors 104 of the system 100 are configured to automatically prepare the bid proposal for the tender document, using the closest historical tender document and a bid value present in an associated bid proposal corresponding to the closest historical tender document, if the closest historical tender document for the tender document is identified at step 214 of the method 200. If the closest historical tender document for the tender document is not identified, then the bid proposal for the tender document, is automatically prepared using the one or more key attributes of the tender document. A rule based natural language generation (NLG) technique is used to automatically prepare the bid proposal for the tender document.
[076] If the closest historical tender document for the tender document is identified, then one or more tender parameters and associated tender parameter

values, and one or more non-tender parameters and associated non-tender parameter values, are identified from the closest historical tender document identified for the tender document. The one or more tender parameters may be typically present in the tender document. The one or more tender parameters may be associated with the technical specification of the component or the product mentioned in the project. For example, in case of the requisition of 100 turbine machines, the one or more tender parameters may be thickness of the drum, power of the rotor assembly, operating speed of the turbine machine, and so on. As the closest tender document is identified, the same tender parameters may be available in the associated bid proposal. However, the tender parameter values for the one or more tender parameters are taken from the tender document.
[077] The one or more non-tender parameters may not be present in the tender document, however, they may be already specified in the bid proposal document corresponding to the closest historical tender document. For example, the non-tender parameters may be electrical switches, wires, bolts, and so on. Hence, the one or more non-tender parameters and the associated non-tender parameter values for the one or more non-tender parameters present in the bid proposal document are directly considered for preparing the bid proposal.
[078] Then, the rule based natural language generation (NLG) technique includes a rule based natural language processing (NLP) engine which contains a set of rules to aautomatically prepare the bid proposal for the tender document, based on (i) the one or more tender parameters and the associated tender parameter values, (ii) the one or more non-tender parameters and the associated non-tender parameter values, and (iii) the bid value associated with the closest historical tender document.
[079] If the closest historical tender document for the tender document is not identified, then the one or more tender parameters and associated tender parameter values are identified from the one or more key attributes of the tender document. Next, the one or more non-tender parameters and associated non-tender parameter values for the one or more non-tender parameters are generated by the rule based natural language processing (NLP) engine. The bid value for the tender

document, is then calculated based on (i) the one or more tender parameters and the associated tender parameter values and (ii) the one or more non-tender parameters and the associated non-tender parameter value. Finally, the bid proposal for the tender document, is prepared based on (i) the one or more tender parameters and the associated tender parameter values, (ii) the one or more non-tender parameters and the associated non-tender parameter values, and (iii) the bid value generated for the tender document, using the rule based natural language generation (NLG) technique.
[080] At step 218 of the method 200, the one or more hardware processors 104 of the system 100 are configured to automatically, commercials and bills of materials (BOM), from the tender receiver. The prepared bid proposal for the tender document is screened by the finance department to include commercials and bills of materials (BOM) to calculate and update the final bid amount in the prepared bid proposal. At step 220 of the method 200, the one or more hardware processors 104 of the system 100 are configured to automatically update the bid proposal prepared for the tender document, with the commercials and bills of materials, to obtain a final bid proposal. In an embodiment, a manual verification confirmation may be provided as an additional check point before submitting the final bid proposal.
[081] At step 222 of the method 200, the one or more hardware processors 104 of the system 100 are configured to automatically submit the final bid proposal corresponding to the tender document, to the tender issuer, by the tender receiver. Further, at step 224 of the method 200, the one or more hardware processors 104 of the system 100 are configured to automatically store the tender document and the final bid proposal corresponding to the tender document, as historical documents in the historical repository for future use.
[082] In accordance with the present disclosure, the methods and systems for automated preparation of the bid proposal, of the present disclosure, prepares the bid proposal automatically from end-to-end. Hence a lot of time, efforts and human resources are saved. Also, the prepared bid proposal is accurate, as humans are not involved. The methods and systems of the present disclosure may accurately

estimate the bid amounts by considering all the parameters present in the tender document.
[083] 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.
[084] 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 processing components 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.
[085] 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 components described herein may be implemented in other components or combinations of other components. 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.
[086] 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 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.
[087] 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.

[088] It is intended that the disclosure and examples be considered as exemplary only, with a true scope of disclosed embodiments being indicated by the following claims.

We Claim:
1. A processor-implemented method (200) for automated preparation of a bid
proposal and management, the method (200) comprising the steps of:
receiving, via one or more hardware processors, by a tender receiver, a tender document, from a tender issuer, for which the bid proposal to be prepared, wherein the tender document comprises at least one or more requirements defined by the tender issuer (202);
extracting, via the one or more hardware processors, one or more key attributes, from the tender document, using a human reading mimicking technique and a domain ontology, wherein the one or more key attributes are associated with the at least one or more requirements (204);
initiating, via the one or more hardware processors, a first check point to check whether (i) the one or more key attributes are feasible, or (ii) the one or more key attributes are infeasible, based on one or more feasibility rules in a predefined feasibility criteria (206);
extracting, via the one or more hardware processors, one or more common key attributes and one or more department wise key attributes, from the tender document, using the human reading mimicking technique and the domain ontology, if the one or more key attributes are feasible at the first check point, wherein the one or more common key attributes and the one or more department wise key attributes are associated with the at least one or more requirements (208);
performing, via the one or more hardware processors, a deviations check criteria to check one of: (i) one or more deviations are present in the tender document, and (ii) the one or more deviations are absent in the tender document, based on the one or more common key attributes and the one or more department wise key attributes, and to receive clarifications from a tender issuer, if the one or more deviations are present in the tender document (210);
initiating, via the one or more hardware processors, a second check point to check whether (i) the one or more common key attributes and the

one or more department wise key attributes are feasible, or (ii) the one or more common key attributes and the one or more department wise key attributes are infeasible, based on (i) the clarifications, if the one or more deviations are present in the tender document, and (ii) the one or more feasibility rules in the predefined feasibility criteria (212);
identifying, via the one or more hardware processors, a closest historical tender document for the tender document, using a trained closest tender document identification model, if the one or more common key attributes and the one or more department wise key attributes are feasible at the second check point (214); and
automatically preparing, via the one or more hardware processors, the bid proposal for the tender document, using one of: (i) the closest historical tender document and a bid value present in an associated bid proposal corresponding to the closest historical tender document, if the closest historical tender document for the tender document is identified, and (ii) the one or more key attributes of the tender document, if the closest historical tender document for the tender document is not identified, using a rule based natural language generation (NLG) technique (216).
2. The method as claimed in claim 1, further comprising:
receiving, via the one or more hardware processors, commercials and bills of materials, from the tender receiver (218);
updating, via the one or more hardware processors, the bid proposal prepared for the tender document, with the commercials and bills of materials, to obtain a final bid proposal (220);
submitting, via the one or more hardware processors, the final bid proposal corresponding to the tender document, to the tender issuer (222); and
storing, via the one or more hardware processors, the tender document and the final bid proposal corresponding to the tender document, in a historical repository (224).

3. The method as claimed in claim 1, wherein extracting the one or more key
attributes, from the tender document, using the human reading mimicking
technique and the domain ontology, further comprises:
identifying one or more contents, from the tender document, using a document extraction technique;
extracting a plurality of keywords from each content of the one or more contents, using the human reading mimicking technique; and
extracting the one or more key attributes from the plurality of keywords, using the domain ontology.
4. The method as claimed in claim 1, wherein extracting the one or more
common key attributes and one or more department wise key attributes,
from the tender document, using the human reading mimicking technique
and the domain ontology, if the one or more key attributes are is feasible at
the first check point, further comprises:
identifying one or more contents, from the tender document, using a document extraction technique;
extracting a plurality of keywords from each content of the one or more contents, using the human reading mimicking technique; and
extracting the one or more common key attributes and the one or more department wise key attributes, from the plurality of keywords, using the domain ontology.
5. The method as claimed in claim 1, wherein the trained closest tender
document identification model is obtained by:
receiving a plurality of historical tender documents, from a historical repository;
extracting (i) the one or more key attributes, (ii) the one or more common key attributes, and (iii) the one or more department wise key attributes, for each historical tender document of the

plurality of historical tender documents, using the human reading mimicking technique and the domain ontology;
generating a key attribute weight for each key attribute of the one or more key attributes, a common key attribute weight for each common key attribute of the one or more common key attributes, and a department wise key attribute weight for each department wise key attribute of the one or more department wise key attributes, for each historical tender document of the plurality of historical tender documents, using a natural language tool;
calculating a total key attribute weight for each historical tender document of the plurality of historical tender documents, by adding the key attribute weight for each key attribute of the one or more key attributes, the common key attribute weight for each common key attribute of the one or more common key attributes, and the department wise key attribute weight for each department wise key attribute of the one or more department wise key attributes; and
training a long short-term memory based network with (i) the one or more key attributes, the one or more common key attributes, and the one or more department wise key attributes, and (ii) the total key attribute weight, for each historical tender document of the plurality of historical tender documents, to obtain the trained closest tender document identification model, by:
(i) passing the one or more key attributes, the one or more common key attributes, and the one or more department wise key attributes, for each historical tender document, to the long short-term memory based network, to obtain a predicted key attribute weight for each key attribute of the one or more key attributes, a predicted common key attribute weight for each common key attribute of the one or more common key attributes, and a predicted department

wise key attribute weight for each department wise key attribute of the one or more department wise key attributes, for each historical tender document;
(ii) calculating a total predicted key attribute weight for each historical tender document, by adding the predicted key attribute weight for each key attribute of the one or more key attributes, the predicted common key attribute weight for each common key attribute of the one or more common key attributes, and the predicted department wise key attribute weight for each department wise key attribute of the one or more department wise key attributes;
(iii) optimizing an objective function that minimizes an error between (i) the total predicted key attribute weight for each historical tender document, and (ii) the total key attribute weight for each historical tender document; and
(iv) updating model weights of the long short-term memory based network, based on the objective function.
6. The method as claimed in claim 5, wherein:
(i) extracting the one or more key attributes for each historical tender document of the plurality of historical tender documents, using the human reading mimicking technique and the domain ontology, comprises:
identifying one or more contents, from each historical tender document, using a document extraction technique;
extracting a plurality of keywords from each content of the one or more contents identified from each historical tender document, using the human reading mimicking technique; and

extracting the one or more key attributes from the
plurality of keywords, for each historical tender document,
using the domain ontology.
(ii) extracting the one or more common key attributes and the one or more
department wise key attributes, for each historical tender document of
the plurality of historical tender documents, using the human reading
mimicking technique and the domain ontology, comprises:
identifying one or more contents, from each historical tender document, using a document extraction technique;
extracting a plurality of keywords from each content of the one or more contents identified for each historical tender document, using the human reading mimicking technique; and
extracting the one or more common key attributes and the one or more department wise key attributes, from the plurality of keywords, for each historical tender document, using the domain ontology.
7. The method as claimed in claim 1, wherein automatically preparing the bid proposal for the tender document, based on the closest historical tender document and the bid value present in the associated bid proposal corresponding to the closest historical tender document, if the closest historical tender document for the tender document is identified, using the rule based natural language generation (NLG) technique, further comprises:
identifying (i) one or more tender parameters and associated tender parameter values, and (ii) one or more non-tender parameters and associated non-tender parameter values, from the closest historical tender document identified for the tender document; and
automatically preparing the bid proposal for the tender document, based on (i) the one or more tender parameters and the associated tender

parameter values, (ii) the one or more non-tender parameters and the associated non-tender parameter values, and (iii) the bid value associated with the closest historical tender document, using the rule based natural language generation (NLG) technique.
8. The method as claimed in claim 1, wherein automatically preparing the bid
proposal for the tender document, based on the one or more key attributes
of the tender document, if the closest historical tender document for the
tender document is not identified, using the rule based natural language
generation (NLG) technique, further comprises:
identifying one or more tender parameters and associated tender parameter values, from the one or more key attributes of the tender document;
generating one or more non-tender parameters and associated non-tender parameter values for the one or more non-tender parameters;
calculating a bid value for the tender document, based on (i) the one or more tender parameters and the associated tender parameter values and (ii) the one or more non-tender parameters and the associated non-tender parameter value; and
automatically preparing the bid proposal for the tender document, based on (i) the one or more tender parameters and the associated tender parameter values, (ii) the one or more non-tender parameters and the associated non-tender parameter values, and (iii) the bid value generated for the tender document, using the rule based natural language generation (NLG) technique.
9. The method as claimed in claim 1, wherein identifying the closest historical
tender document for the tender document, using the trained closest tender
document identification model, if the one or more common key attributes

and the one or more department wise key attributes are feasible at the second check point, further comprises:
passing the one or more key attributes, the one or more common key attributes and the one or more department wise key attributes, corresponding to (i) the tender document and (ii) each historical tender document of a plurality of historical tender documents, to the trained closest tender document identification model, to obtain a total predicted key attribute weight for the tender document and each historical tender document, respectively;
finding one or more historical tender documents out of the plurality of historical tender documents, having the total predicted key attribute weight more than a predefined key attribute weight, if the total predicted key attribute weight for the tender document is greater than the predefined key attribute weight;
calculating a distance metric between (i) the tender document and (ii) each historical tender document of the one or more historical tender documents; and
identifying the historical tender document among the one or more historical tender documents, having a least distance metric, as the closest historical tender document for the tender document.
10. A system (100) for automated preparation of a bid proposal and management, the system (100) comprising: a memory (102) storing instructions;
one or more Input/Output (I/O) interfaces (106); and
one or more hardware processors (104) coupled to the memory (102) via the one or more I/O interfaces (106), wherein the one or more hardware processors (104) are configured by the instructions to:
receive, by a tender receiver, a tender document, from a tender issuer, for which the bid proposal to be prepared, wherein the tender

document comprises at least one or more requirements defined by the tender issuer;
extract one or more key attributes, from the tender document, using a human reading mimicking technique and a domain ontology, wherein the one or more key attributes are associated with the at least one or more requirements;
initiate a first check point to check whether (i) the one or more key attributes are feasible, or (ii) the one or more key attributes are infeasible, based on one or more feasibility rules in a predefined feasibility criteria;
extract one or more common key attributes and one or more department wise key attributes, from the tender document, using the human reading mimicking technique and the domain ontology, if the one or more key attributes are feasible at the first check point, wherein the one or more common key attributes and the one or more department wise key attributes are associated with the at least one or more requirements;
perform a deviations check criteria to check one of: (i) one or more deviations are present in the tender document, and (ii) the one or more deviations are absent in the tender document, based on the one or more common key attributes and the one or more department wise key attributes, and to receive clarifications from a tender issuer, if the one or more deviations are present in the tender document;
initiate a second check point to check whether (i) the one or more common key attributes and the one or more department wise key attributes are feasible, or (ii) the one or more common key attributes and the one or more department wise key attributes are infeasible, based on (i) the clarifications, if the one or more deviations are present in the tender document, and (ii) the one or more feasibility rules in the predefined feasibility criteria;
identify a closest historical tender document for the tender document, using a trained closest tender document identification model, if

the one or more common key attributes and the one or more department wise key attributes are feasible at the second check point; and
automatically prepare the bid proposal for the tender document, using one of: (i) the closest historical tender document and a bid value present in an associated bid proposal corresponding to the closest historical tender document, if the closest historical tender document for the tender document is identified, and (ii) the one or more key attributes of the tender document, if the closest historical tender document for the tender document is not identified, using a rule based natural language generation (NLG) technique.
11. The system as claimed in claim 10, wherein the one or more hardware
processors (104) are further configured to:
receive commercials and bills of materials, from the tender receiver;
update the bid proposal prepared for the tender document, with the commercials and bills of materials, to obtain a final bid proposal;
submit the final bid proposal corresponding to the tender document, to the tender issuer; and
store the tender document and the final bid proposal corresponding to the tender document, in a historical repository.
12. The system as claimed in claim 10, wherein the one or more hardware
processors (104) are configured to extract the one or more key attributes,
from the tender document, using the human reading mimicking technique
and the domain ontology, by
identifying one or more contents, from the tender document, using a document extraction technique;
extracting a plurality of keywords from each content of the one or more contents, using the human reading mimicking technique; and
extracting the one or more key attributes from the plurality of keywords, using the domain ontology.

13. The system as claimed in claim 10, wherein the one or more hardware
processors (104) are configured to extract the one or more common key
attributes and one or more department wise key attributes, from the tender
document, using the human reading mimicking technique and the domain
ontology, if the one or more key attributes are is feasible at the first check
point, by:
identifying one or more contents, from the tender document, using a document extraction technique;
extracting a plurality of keywords from each content of the one or more contents, using the human reading mimicking technique; and
extracting the one or more common key attributes and the one or more department wise key attributes, from the plurality of keywords, using the domain ontology.
14. The system as claimed in claim 10, wherein the one or more hardware
processors (104) are configured to obtain the trained closest tender
document identification model, by:
receiving a plurality of historical tender documents, from a historical repository;
extracting (i) the one or more key attributes, (ii) the one or more common key attributes, and (iii) the one or more department wise key attributes, for each historical tender document of the plurality of historical tender documents, using the human reading mimicking technique and the domain ontology;
generating a key attribute weight for each key attribute of the one or more key attributes, a common key attribute weight for each common key attribute of the one or more common key attributes, and a department wise key attribute weight for each department wise key attribute of the one or more department wise key attributes, for

each historical tender document of the plurality of historical tender documents, using a natural language tool;
calculating a total key attribute weight for each historical tender document of the plurality of historical tender documents, by adding the key attribute weight for each key attribute of the one or more key attributes, the common key attribute weight for each common key attribute of the one or more common key attributes, and the department wise key attribute weight for each department wise key attribute of the one or more department wise key attributes; and
training a long short-term memory based network with (i) the one or more key attributes, the one or more common key attributes, and the one or more department wise key attributes, and (ii) the total key attribute weight, for each historical tender document of the plurality of historical tender documents, to obtain the trained closest tender document identification model, by:
(i) passing the one or more key attributes, the one or more common key attributes, and the one or more department wise key attributes, for each historical tender document, to the long short-term memory based network, to obtain a predicted key attribute weight for each key attribute of the one or more key attributes, a predicted common key attribute weight for each common key attribute of the one or more common key attributes, and a predicted department wise key attribute weight for each department wise key attribute of the one or more department wise key attributes, for each historical tender document;
(ii) calculating a total predicted key attribute weight for each historical tender document, by adding the predicted key attribute weight for each key attribute of the one or more key attributes, the predicted common key attribute weight for

each common key attribute of the one or more common key attributes, and the predicted department wise key attribute weight for each department wise key attribute of the one or more department wise key attributes;
(iii) optimizing an objective function that minimizes an error between (i) the total predicted key attribute weight for each historical tender document, and (ii) the total key attribute weight for each historical tender document; and
(iv) updating model weights of the long short-term memory based network, based on the objective function.
15. The system as claimed in claim 14, wherein the one or more hardware processors (104) are further configured to:
(i) extract the one or more key attributes for each historical tender document of the plurality of historical tender documents, using the human reading mimicking technique and the domain ontology, by:
identifying one or more contents, from each historical tender document, using a document extraction technique;
extracting a plurality of keywords from each content of the one or more contents identified from each historical tender document, using the human reading mimicking technique; and
extracting the one or more key attributes from the
plurality of keywords, for each historical tender document,
using the domain ontology.
(ii) extract the one or more common key attributes and the one or more
department wise key attributes, for each historical tender document of
the plurality of historical tender documents, using the human reading
mimicking technique and the domain ontology, by:

identifying one or more contents, from each historical tender document, using a document extraction technique;
extracting a plurality of keywords from each content of the one or more contents identified for each historical tender document, using the human reading mimicking technique; and
extracting the one or more common key attributes and the one or more department wise key attributes, from the plurality of keywords, for each historical tender document, using the domain ontology.
16. The system as claimed in claim 10, wherein the one or more hardware processors (104) are configured to automatically prepare the bid proposal for the tender document, based on the closest historical tender document and the bid value present in the associated bid proposal corresponding to the closest historical tender document, if the closest historical tender document for the tender document is identified, using the rule based natural language generation (NLG) technique, by:
identifying (i) one or more tender parameters and associated tender parameter values, and (ii) one or more non-tender parameters and associated non-tender parameter values, from the closest historical tender document identified for the tender document; and
automatically preparing the bid proposal for the tender document, based on (i) the one or more tender parameters and the associated tender parameter values, (ii) the one or more non-tender parameters and the associated non-tender parameter values, and (iii) the bid value associated with the closest historical tender document, using the rule based natural language generation (NLG) technique.

17. The system as claimed in claim 10, wherein the one or more hardware
processors (104) are configured to automatically prepare the bid proposal
for the tender document, based on the one or more key attributes of the
tender document, if the closest historical tender document for the tender
document is not identified, using the rule based natural language generation
(NLG) technique, by:
identifying one or more tender parameters and associated tender parameter values, from the one or more key attributes of the tender document;
generating one or more non-tender parameters and associated non-tender parameter values for the one or more non-tender parameters;
calculating a bid value for the tender document, based on (i) the one or more tender parameters and the associated tender parameter values and (ii) the one or more non-tender parameters and the associated non-tender parameter value; and
automatically preparing the bid proposal for the tender document, based on (i) the one or more tender parameters and the associated tender parameter values, (ii) the one or more non-tender parameters and the associated non-tender parameter values, and (iii) the bid value generated for the tender document, using the rule based natural language generation (NLG) technique.
18. The system as claimed in claim 10, wherein the one or more hardware
processors (104) are configured to identify the closest historical tender
document for the tender document, using the trained closest tender
document identification model, if the one or more common key attributes
and the one or more department wise key attributes are feasible at the second
check point, by:
passing the one or more key attributes, the one or more common key attributes and the one or more department wise key attributes, corresponding

to (i) the tender document and (ii) each historical tender document of a plurality of historical tender documents, to the trained closest tender document identification model, to obtain a total predicted key attribute weight for the tender document and each historical tender document, respectively;
finding one or more historical tender documents out of the plurality of historical tender documents, having the total predicted key attribute weight more than a predefined key attribute weight, if the total predicted key attribute weight for the tender document is greater than the predefined key attribute weight;
calculating a distance metric between (i) the tender document and (ii) each historical tender document of the one or more historical tender documents; and
identifying the historical tender document among the one or more historical tender documents, having a least distance metric, as the closest historical tender document for the tender document.