Patent Application
20240378557
The present invention generally relates to digitizing documents and testing requirements identified within the digitized document on a telecom network.
Existing solutions for document and network management are manual, disaggregated and reactive. Currently, there is no end-to-end solution, which automatically extracts requirements from documents, creates databases and triggers automated testing of a network. In addition to the above all finance and accounting related actions related to deliverables, quality of the network and more are mainly executed manually.
Accordingly, an improved and/or alternative approach may be beneficial.
Certain embodiments of the present invention may provide solutions to the problems and needs in the art that have not yet been fully identified, appreciated, or solved by current application and network compliance testing technologies, and/or provide a useful alternative thereto. For example, some embodiments of the present invention pertain to digitizing a document and analyzing and/or crawling a telecom network to verify if requirements in the digitized documents are fulfilled.
In an embodiment, a computing system includes memory storing computer program instructions and at least one processor configured to execute the computer program instructions. The computer program instructions are configured to cause the at least one processor to execute digitizing a document into a standard digital format, storing the digitized document in an authoritative CTR governance database, and organizing a plurality of technical requirements extracted from the digitized contract within the authoritative CTR governance database. The computer program instructions are further configured to cause the at least one processor execute linking a plurality of network function test cases to the plurality of technical requirements, and storing a plurality of results in the authoritative CTR governance database.
In another embodiment, a non-transitory computer-readable medium comprising a computer program. The computer program is configured to cause at least one processor to execute digitizing a document into a standard digital format, storing the digitized document in an authoritative CTR governance database, and organizing a plurality of technical requirements extracted from the digitized contract within the authoritative CTR governance database. The computer program is further configured to cause at least one processor to execute linking a plurality of network function test cases to the plurality of technical requirements, and storing a plurality of results in the authoritative CTR governance database.
In yet another embodiment, a computer-implemented method includes digitizing a document into a standard digital format, storing the digitized document in an authoritative CTR governance database, and organizing a plurality of technical requirements extracted from the digitized contract within the authoritative CTR governance database. The computer-implemented method also includes linking a plurality of network function test cases to the plurality of technical requirements, and storing a plurality of results in the authoritative CTR governance database.
In order that the advantages of certain embodiments of the invention will be readily understood, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments that are illustrated in the appended drawings. While it should be understood that these drawings depict only typical embodiments of the invention and are not therefore to be considered to be limiting of its scope, the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which:
Unless otherwise indicated, similar reference characters denote corresponding features consistently throughout the attached drawings.
Some embodiments pertain to the digitization of documents containing parameters for how the network should be operating or how the network should be deployed. The digitized document is placed in an authoritative datastore (e.g., the authoritative Contributor (CTR)>governance DB). From there, test cases are built or created from the requirements that are now in the authoritative datastore. The test cases are then executed to test the network for specific requirements and the information (or test results) is written into the authoritative datastore. This allows for a matrix of technical requirements for each contract to be considered, and determine how the application or service is behaving on the network.
Under Technical Requirements Table (a), requirements (e.g., technical) in the contract are structured in table and matrix format. For each contract at any given time, the matrix may catalog the expectation of the application or technology deployed on a network. The tables allow for data feedback on those technical requirements.
The technical requirements table is a part of the authoritative data store that orchestrates and organizes the relationships between technical requirements, the test cases for those requirements, and the network functions they correlate to. This is also the core of what enables tracking and compliance of technical requirements.
Under CTR Tables (b), CTR information is organized in a table format.
The CTR table is a part of the authoritative datastore that keeps entities deploying on the network organized.
Legal Tables (c) includes tables used for pointing to documents, as shown in
Let's say for example a CTR contract is accessed for any contributor and the contract (or document) is digitized. The digitized document (i.e., the JSON file) is then stored in a document type ID 2 folder, and another folder (i.e., a subfolder) is created. This other folder (or folders) may store any assets or diagrams extracted from the contract.
The reason for this configuration is, there may be application packages that tabularizes the digitized documents (or files). Simply put, the open source packages take the digitized document from an unstructured format to a structured format (i.e., table format), thereby allowing for queries to be run against the tables. This allows for efficient queries to be run against the tables.
For purposes of explanation only, a digitized document is a JSON structure that organizes extracted information from the legal document (or contract). The idea is to pull out the metadata in the contract. This metadata may include the partners in the contract, the terms, effective date, and end date. By digitizing all of the sections and subsections, each paragraph, along with the content, is placed in another format that is in a JSON readable format. Further, nested under each paragraph, there may be a requirement section. In some embodiments, there may be a repository of requirement types. This may include a due date, a payment milestone, etc. For example, if a requirement is present within the paragraph, a ‘1’ will be listed to identify that there is a requirement present. Under this, there may be requirement types and any relevant information (e.g., deadlines) for the requirement.
In terms of pre-processing, the code (or algorithm) provides a user interface for a user 235 or external user 240 to login and upload a file. Additionally, user 235 or external user 240 may identify the specific phrases within the contract, the associated project, etc. Once the information is submitted, the code is executed on the back end. In certain embodiments, there are two aspects that are running at the same time. First part is creating the JSON file, which allows for the digitized document. The second part is the uploading (including extracting of the data from the document) of the JSON file into the tracking software.
Once this is complete, all of the ticket numbers associated with the tickets created for the paragraphs in the contracts are also added back into the JSON, YAML, or other file types. This way, the ticket numbers can be tracked within the file. See, for example,
For uploading a digitized contract, including all extracted materials, into a tracking software, an issue is created in Jira for each section extracted from the contract. Although Jira is discussed in this embodiment, any tracking software may be used. Each issue being created uses the section name extracted directly from the contract and the unique section ID programmatically assigned to the section. The algorithm may then write back the issue IDs created in the tracking software so that the subsection level of the JSON is updated and uploaded into the software with the correct dependencies.
In some embodiments, the digitized version of the document may also be downloaded, if necessary. This digitized document is easily indexable; meaning that a query can be run to return all relevant information for a specific attribute in a JSON file. For example, if all requirements for a specific type of attribute or component across multiple vendors were needed; because the document is digitized in an indexable format, the query can return the relevant information about specifications and timelines.
In some embodiments, ML modules are used to extract data from the document. Since there may be keywords that differ from one document to another, the words that are used to imply deliverable may be different. With natural language processing (NLP), it may be easier to predict or find minute changes in jargon.
Another way ML modules may be used is for the extraction of metadata. By building ML models that contain historical metadata, the ML modules may extract the metadata from the document.
A digitized document management database 215 may store the digitized document, which may be accessed by an internal user 235, authorized external user 240, and/or authoritative CTR governance database 220. For example, an internal user 235 or an authorized external user 240 may access the digital contract to pull technical requirements mentioned and the agreed upon level of commitment by both parties.
Authoritative CTR governance database 220 may communicate with the digitized document management database 215, and may store requirements extracted from the digitized contract. This digitized document management database 215 stores all information mentioned in the contract including, but not limited to, deliverables, technical requirements, deadlines, financial commitments, all clauses, dates and any information provided in a contract.
Integrated network testing modules 215 may include test cases, which are built around requirements within authoritative CTR governance database 220. In some embodiments, the test cases may be executed internally or externally to test network 230. By way of example, an internal test may be described as testing the latency of a point to point connection. An external test may be described as testing being done by external partners, which will provide information on the performance of the network.
Based on the result of the test case, integrated network testing modules 225 may be in communication with authoritative CTR governance database 220, and may write the results back to authoritative CTR governance database 220. This allows for a user to review the technical requirements of each digitized contract and understand how that application or service is behaving on network 230. In certain embodiments, the results of the test cases and the associated test cases may be stored in a ML database or ML model (not shown). This allow the ML module to build test cases based on one or more digitized documents.
In some additional embodiments, automated payment modules 250 may access service level agreements in authoritative CTR governance database 220, and may automate invoices based on the terms and conditions listed in the service level agreements. For example, if there are deliverables, fees or credits identified in the contract, the platform kicks off payments based on the live network data.
In some embodiments, business intelligence dashboard 245 is configured to provide a live status of the contract deliverables, partner deliverables on network 230 and more to stakeholders.
Computing system 400 further includes a memory 415 for storing information and instructions to be executed by processor(s) 410. Memory 415 can be comprised of any combination of random access memory (RAM), read-only memory (ROM), flash memory, cache, static storage such as a magnetic or optical disk, or any other types of non-transitory computer-readable media or combinations thereof. Non-transitory computer-readable media may be any available media that can be accessed by processor(s) 410 and may include volatile media, non-volatile media, or both. The media may also be removable, non-removable, or both.
Additionally, computing system 400 includes a communication device 420, such as a transceiver, to provide access to a communications network via a wireless and/or wired connection. In some embodiments, communication device 420 may be configured to use Frequency Division Multiple Access (FDMA), Single Carrier FDMA (SC-FDMA), Time Division Multiple Access (TDMA), Code Division Multiple Access (CDMA), Orthogonal Frequency Division Multiplexing (OFDM), Orthogonal Frequency Division Multiple Access (OFDMA), Global System for Mobile (GSM) communications, General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), cdma2000, Wideband CDMA (W-CDMA), High-Speed Downlink Packet Access (HSDPA), High-Speed Uplink Packet Access (HSUPA), High-Speed Packet Access (HSPA), Long Term Evolution (LTE), LTE Advanced (LTE-A), 802.11x, Wi-Fi, Zigbee, Ultra-WideBand (UWB), 802.16x, 802.15, Home Node-B (HnB), Bluetooth, Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Near-Field Communications (NFC), fifth generation (5G), New Radio (NR), any combination thereof, and/or any other currently existing or future-implemented communications standard and/or protocol without deviating from the scope of the invention. In some embodiments, communication device 520 may include one or more antennas that are singular, arrayed, phased, switched, beamforming, beamsteering, a combination thereof, and or any other antenna configuration without deviating from the scope of the invention.
Processor(s) 410 are further coupled via bus 405 to a display 425, such as a plasma display, a Liquid Crystal Display (LCD), a Light Emitting Diode (LED) display, a Field Emission Display (FED), an Organic Light Emitting Diode (OLED) display, a flexible OLED display, a flexible substrate display, a projection display, a 4K display, a high definition display, a Retina® display, an In-Plane Switching (IPS) display, or any other suitable display for displaying information to a user. Display 425 may be configured as a touch (haptic) display, a three-dimensional (3D) touch display, a multi-input touch display, a multi-touch display, etc. using resistive, capacitive, surface-acoustic wave (SAW) capacitive, infrared, optical imaging, dispersive signal technology, acoustic pulse recognition, frustrated total internal reflection, etc. Any suitable display device and haptic I/O may be used without deviating from the scope of the invention.
A keyboard 430 and a cursor control device 435, such as a computer mouse, a touchpad, etc., are further coupled to bus 405 to enable a user to interface with computing system 400. However, in certain embodiments, a physical keyboard and mouse may not be present, and the user may interact with the device solely through display 425 and/or a touchpad (not shown). Any type and combination of input devices may be used as a matter of design choice. In certain embodiments, no physical input device and/or display is present. For instance, the user may interact with computing system 400 remotely via another computing system in communication therewith, or computing system 400 may operate autonomously.
Memory 415 stores software modules that provide functionality when executed by processor(s) 410. The modules include an operating system 540 for computing system 400. The modules further include a network management module 445 that is configured to perform all or part of the processes described herein or derivatives thereof. Computing system 400 may include one or more additional functional modules 450 that include additional functionality.
One skilled in the art will appreciate that a “computing system” could be embodied as a server, an embedded computing system, a personal computer, a console, a personal digital assistant (PDA), a cell phone, a tablet computing device, a quantum computing system, or any other suitable computing device, or combination of devices without deviating from the scope of the invention. Presenting the above-described functions as being performed by a “system” is not intended to limit the scope of the present invention in any way, but is intended to provide one example of the many embodiments of the present invention. Indeed, methods, systems, and apparatuses disclosed herein may be implemented in localized and distributed forms consistent with computing technology, including cloud computing systems. The computing system could be part of or otherwise accessible by a local area network (LAN), a mobile communications network, a satellite communications network, the Internet, a public or private cloud, a hybrid cloud, a server farm, any combination thereof, etc. Any localized or distributed architecture may be used without deviating from the scope of the invention.
It should be noted that some of the system features described in this specification have been presented as modules, in order to more particularly emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom very large scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, or the like.
A module may also be at least partially implemented in software for execution by various types of processors. An identified unit of executable code may, for instance, include one or more physical or logical blocks of computer instructions that may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together, but may include disparate instructions stored in different locations that, when joined logically together, comprise the module and achieve the stated purpose for the module. Further, modules may be stored on a computer-readable medium, which may be, for instance, a hard disk drive, flash device, RAM, tape, and/or any other such non-transitory computer-readable medium used to store data without deviating from the scope of the invention.
Indeed, a module of executable code could be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network.
The process steps performed in
The computer program(s) can be implemented in hardware, software, or a hybrid implementation. The computer program(s) can be composed of modules that are in operative communication with one another, and which are designed to pass information or instructions to display. The computer program(s) can be configured to operate on a computing system, an ASIC, or any other suitable device.
It will be readily understood that the components of various embodiments of the present invention, as generally described and illustrated in the figures herein, may be arranged and designed in a wide variety of different configurations. Thus, the detailed description of the embodiments of the present invention, as represented in the attached figures, is not intended to limit the scope of the invention as claimed, but is merely representative of selected embodiments of the invention.
The features, structures, or characteristics of the invention described throughout this specification may be combined in any suitable manner in one or more embodiments. For example, reference throughout this specification to “certain embodiments,” “some embodiments,” or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases “in certain embodiments,” “in some embodiment,” “in other embodiments,” or similar language throughout this specification do not necessarily all refer to the same group of embodiments and the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
It should be noted that reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present invention should be or are in any single embodiment of the invention. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present invention. Thus, discussion of the features and advantages, and similar language, throughout this specification may, but do not necessarily, refer to the same embodiment.
Furthermore, the described features, advantages, and characteristics of the invention may be combined in any suitable manner in one or more embodiments. One skilled in the relevant art will recognize that the invention can be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the invention.
One having ordinary skill in the art will readily understand that the invention as discussed above may be practiced with steps in a different order, and/or with hardware elements in configurations which are different than those which are disclosed. Therefore, although the invention has been described based upon these preferred embodiments, it would be apparent to those of skill in the art that certain modifications, variations, and alternative constructions would be apparent, while remaining within the spirit and scope of the invention. In order to determine the metes and bounds of the invention, therefore, reference should be made to the appended claims.
