Patent Application
20210183097
A physical assembly may include a large number of constituent parts. During operation, a part within the assembly may fail or otherwise require replacement due to normal wear and tear. For assemblies containing a large number of parts across a range of sizes, identifying a particular part for replacement through manual inspection may be cumbersome. Further, in certain instances, differentiating one part from another may be difficult.
The detailed description is set forth with reference to the accompanying drawings. The drawings are provided for purposes of illustration only and merely depict example embodiments of the disclosure. The drawings are provided to facilitate understanding of the disclosure and shall not be deemed to limit the breadth, scope, or applicability of the disclosure. In the drawings, the left-most digit(s) of a reference numeral identifies the drawing in which the reference numeral first appears. The use of the same reference numerals indicates similar, but not necessarily the same or identical components. However, different reference numerals may be used to identify similar components as well. Various embodiments may utilize elements or components other than those illustrated in the drawings, and some elements and/or components may not be present in various embodiments. The use of singular terminology to describe a component or element may, depending on the context, encompass a plural number of such components or elements and vice versa.
This disclosure relates to, among other things, devices, servers, systems, methods, computer-readable media, techniques, and methodologies for automated identification of parts of a parts assembly using depth data and a locally learned database of three-dimensional (3D) keypoint landmarks. The parts assembly may be any machine assembly containing constituent physical parts. For instance, as a non-limiting example, the parts assembly may be train vehicle composed of over one hundred thousand parts including thousands of unique spare parts.
The problem of part identification can be cast as a pose estimation problem. That is, once a pose of a camera/sensor that captures an image of a parts assembly is known, a label map of parts of the parts assembly can be rendered as an overlay over the captured image using a 3D simulated model (e.g., a 3D computer-aided design (CAD) model) of the parts assembly. The 3D CAD model may be represented in 3D space using an XYZ coordinate system. The 3D CAD model may be associated with metadata that may include an identification of the parts of the physical assembly (e.g., part numbers), an identification of the locations of parts within the assembly, and so forth.
As noted above, the part identification problem reduces to one of estimating the camera pose, and conventional approaches for part identification formulate the problem using concepts from image search. More specifically, in one such approach, depth images from multiple viewpoints of a 3D simulated model of a parts assembly (e.g., a 3D CAD model) are sampled and rendered. Each image is then represented in some high-dimensional feature space using a learned model, and a database of feature representations of the images, indexed by pose, is populated. Subsequently, given a query image at testing time, a nearest neighbor search is employed in the learned feature space, and the pose corresponding to the retrieved nearest neighbor is assigned to the query image. Once the pose is assigned to the query image, a label map of parts can be rendered over the query image. More specifically, the 3D CAD model of the parts assembly can be rendered over the query image from a virtual viewpoint representative of the assigned pose which, in turn, corresponds to an actual viewpoint from which the query image was taken. In this manner, the parts of the parts assembly represented by the rendered 3D CAD model may be aligned with parts of the parts assembly captured in the query image with respect to their relative orientations and locations within the assembly. The label map of parts can then be rendered over the query image based on the rendered 3D CAD model that is aligned with the query image.
In conventional approaches such as the one described above, a depth image of the 3D CAD model that is captured by one or more depth sensors often includes background noise and/or noise associated with the portion of the image that includes the object of interest (e.g., a parts assembly). As a result, employing the feature-based approach described above can result in an inaccurate feature representation of the depth image due to the noise, which in turn, can affect the accuracy of the downstream part identification.
Example embodiments address the technical problem of inaccurate feature representations derived from depth images that contain noise and the resulting inaccuracy of downstream part identification by providing a technical solution that includes performing, as part of a training phase, localized representation learning to build a database of 3D keypoint landmarks and local features. Then, during a testing phase, keypoints of a query image are computed, the closest matching points in the 3D keypoint landmark database for each keypoint are determined, and a parameter estimation algorithm is executed to estimate the pose of the query image.
Illustrative methods according to example embodiments of the invention will now be described. Each operation of any of the methods 200-500 may be performed by one or more components that may be implemented in any combination of hardware, software, and/or firmware. In certain example embodiments, one or more of these component(s) may be implemented, at least in part, as software and/or firmware that contains or is a collection of one or more program modules that include computer-executable instructions that when executed by a processing circuit cause one or more operations to be performed. A system or device described herein as being configured to implement example embodiments of the invention may include one or more processing circuits, each of which may include one or more processing units or nodes. Computer-executable instructions may include computer-executable program code that when executed by a processing unit may cause input data contained in or referenced by the computer-executable program code to be accessed and processed to yield output data.
At block 202 of the method 200, in example embodiments, a set of images from multiple viewpoints (poses) are sampled and rendered from a simulated 3D model such as a 3D CAD model. The 3D CAD model may be representative, in example embodiments, of a parts assembly containing a plurality of constituent parts. The set of images sampled and rendered at block 202 may serve as training depth image data 102 that may be provided to a local feature representation machine learning algorithm in accordance with example embodiments.
In example embodiments, the local feature representation machine learning algorithm may be a Siamese convolutional neural network (CNN) that receives, as input, pairs of the training depth images 102, based on which, the Siamese CNN is trained to generate meaningful keypoints and learn keypoint representations jointly for the depth image pairs. Although example embodiments may be described herein in reference to a Siamese CNN, it should be appreciated that alternative machine learning constructs may be employed in example embodiments. Generally speaking, a keypoint may be a point of particular interest in an image. For example, in an image of a planar structure, the keypoints may include points along the edges of the structure as well as points corresponding to the corners of the planar structure. In example embodiments, a keypoint representation may be a feature representation such as a feature vector corresponding to a keypoint.
Referring now specifically to
Referring again to
At block 206 of the method 200, pose annotations of the training depth images 102 may be used to generate pairs of local patches from the input pairs of training depth images 102. More specifically, in example embodiments, the feature extraction network 104 may generate feature maps 106 from the training depth images 102. The feature maps 106 may include feature representations corresponding to points in the training depth images 102. The feature maps 106 may be provided to the RPN 116 which may perform one or more convolution operations to generate the proposed keypoints from the feature maps 106: this includes generating the bounding box prediction 118 for each keypoint and its corresponding score prediction 120. The feature maps 106 may also be provided to the ROI pooling layer(s) 108, which additionally receive the predicted bounding boxes 118 generated by the RPN 116. The predicted bounding boxes 118 may be indicative of the size of local patches around proposed keypoints. In particular, the predicted bounding boxes 118 may indicate a pixel width and a pixel height of the local patch corresponding to each proposed keypoint. In example embodiments, the ROI layer(s) 108 and the sampling layer(s) 110 may generate local feature representations for the keypoints proposed by the RPN 116 as well as organize the keypoints (e.g., the patches that contain the keypoints) into local patch pairs.
At block 208 of the method 200, the Siamese CNN may categorize the local patch pairs into positive or negative labels based at least in part on a 3D distance between the proposed keypoints corresponding to the local patch pairs. More specifically, a 3D distance such as a Euclidean distance may be determined between the proposed keypoints of a local patch pair. In example embodiments, the 3D coordinates of the proposed keypoints may be determined from the 3D simulated model (e.g., the 3D CAD model). In example embodiments, if the determined Euclidean distance satisfies a threshold value (e.g. is less than, or in some embodiments, less than or equal to the threshold value), a positive label is assigned to the corresponding local patch pair, whereas if the determined Euclidean distance does not satisfy the threshold value (e.g., is greater than, or in some embodiments, greater than or equal to the threshold value), a negative label is assigned to the local patch pair. In this manner, a positive or negative label may be assigned to each local patch pair. In example embodiments, a positive label may be represented by a binary 1 and a negative label may be represented by a binary 0, or vice versa.
At block 210 of the method 200, a contrastive loss 112 may be determined with respect to the labeled patch pairs. The contrastive loss function 112 ensures that feature representations of keypoints (also referred to herein as keypoint representations) of local patch pairs that have been assigned a positive label are close in the feature space and that feature representations of keypoints of local patch pairs that have been assigned a negative label are relatively far in the feature space. The measure of distance between keypoint representations may be a Euclidean norm. At block 212 of the method 200, a score loss 122 associated with the proposed keypoints may be determined. In example embodiments, the score less may be a multinomial logistic loss defined as follows:
where N represents the number of keypoints; i indexes over the keypoints; yi′ represents the predicted score for the ith keypoint; and yi represents the label assigned to the local patch pair to which the ith keypoint belongs.
In example embodiments, the above-described score loss function penalizes any proposed keypoints having a low predicted score 120 (e.g., a predicted score 120 below a threshold value) that correspond to a local patch pair that has been assigned a positive label. Referring to the specific multinomial logistic loss function presented above, the loss function seeks to push yi′ as close to 1 as possible when yi is a positive label and push yi′ as close to 0 as possible when yi is a negative label. In effect, the score loss function forces the Siamese CNN to produce high scores for keypoints in a local patch pair that are close to one another in the physical space.
It should be appreciated that the example score loss function presented above is merely illustrative and not exhaustive. For instance, in example embodiments, another monotonically increasing function can be used for the score loss function. As another non-limiting example, in certain example embodiments, a variation of the loss function described above can be employed. In particular, referring to the example loss function above, yi log yi′ is only non-zero and contributing to the score loss 122 when a local patch pair has been assigned a positive label and (1−y1) log (1−yi′) is only non-zero and contributing to the score loss 122 when a local patch pair has been assigned a negative label. Accordingly, in example embodiments, both operands are not contributing to the score loss 122 at the same time (e.g., for the same local patch pair). Thus, in example embodiments, only the first operand yi log yi′ corresponding to only the positively labeled local patch pairs may be used for the score loss function.
At block 214 of the method 200, the contrastive loss 112 and the score loss 122 may be optimized to train the Siamese CNN to perform keypoint detection and generation of view-invariant keypoint representations. More specifically, in example embodiments, errors in the contrastive loss 112 can be backpropagated 114 for each depth image pair to update parameters of the Siamese CNN until the contrastive loss 112 is optimized and the network is trained to generate view-invariant keypoint representations. A view-invariant keypoint representation may be a keypoint representation that corresponds to the same point in physical space regardless of the viewpoint of the image from which the keypoint is extracted. In addition, errors in the score loss 122 can be backpropagated 124 for each depth image pair to update parameters of the Siamese CNN until the score loss 122 is optimized and the network is trained to generate high scoring keypoints that correspond to the same physical location in physical space.
A block 402 of the method 400, the trained network may receive a test depth image as input as part of a testing phase. The input depth image may be generated by any of a variety of suitable depth sensors. The pose associated with the input test depth image (e.g., the viewpoint from which the input image is taken) may be unknown. At block 404 of the method 400, the trained network may be used to determine a set of 2D keypoints in the depth image and their keypoint representations. Then, at block 406 of the method 400, the keypoint representations corresponding to the set of 2D keypoints may be used to search the locally learned 3D keypoint landmark database to locate 3D keypoint landmarks in the database that match the 2D keypoints extracted from the input test depth image. At block 408 of the method 400, 3D locations corresponding to the matching keypoint landmarks may be determined.
More specifically, at blocks 406 and 408 of the method, stored view-invariant keypoint representations in the 3D keypoint landmark database (e.g., feature vectors) that match the keypoint representations (e.g., feature vectors) of the 2D keypoints extracted from the test input depth image may be located and the corresponding 3D locations stored in association with the matching view-invariant keypoint representations may be determined. A feature vector stored in the 3D keypoint landmark database that is determined to match a feature vector corresponding to a 2D keypoint extracted from the test input depth image may be a stored feature vector whose Euclidean distance to the feature vector corresponding to the 2D extracted keypoint is smallest among all stored feature vectors. In example embodiments, the matching process yields a set of one-to-one correspondences between the 2D keypoints extracted from the test input depth image and 3D keypoint landmarks stored in the database. In certain example embodiments, in order to compensate for any misalignment between the matched 3D keypoint landmarks and the corresponding 2D extracted keypoints, patches around each 2D keypoint can be sampled, and the keypoint in a sampled patch that has the smallest Euclidean distance in the feature space to the corresponding matched 3D keypoint landmark can be selected as an updated 2D keypoint.
Finally, at block 410 of the method 400, a parameter estimation algorithm may be executed on the 3D locations of the matching 3D keypoint landmarks to determine a pose corresponding to the input depth image. In example embodiments, the parameter estimation algorithm may parameterize a camera pose using 9 parameters-3 translation parameters and 6 rotation parameters. Generally speaking, the parameter estimation algorithm seeks to estimate a camera pose corresponding to the input test depth image based on a subset of the one-to-one correspondences between the 2D keypoints extracted from the test input depth image and 3D keypoint landmarks stored in the database, and subsequently determine how accurate the estimated pose is with respect to the one-to-one correspondences outside of the subset.
In response to a positive determination at block 506, the estimated pose may be selected as the camera pose corresponding to the test input depth image. On the other hand, in response to a negative determination at block 506, the method 500 may proceed iteratively from block 404 of the method 400, where a new set of 2D keypoints may be extracted from the test input depth image. The parameter estimation algorithm may be iteratively executed in this manner until the algorithm converges to a set of 2D keypoints that yield a pose estimation that results in a re-projection error that is less than the threshold value. Once an acceptable camera pose is identified, an image of the 3D CAD model from a virtual viewpoint corresponding to the camera pose can be rendered as an overlay over the input test depth image. A parts map can then be rendered as an overlay to facilitate part identification.
One or more illustrative embodiments of the disclosure have been described above. The above-described embodiments are merely illustrative of the scope of this disclosure and are not intended to be limiting in any way. Accordingly, variations, modifications, and equivalents of embodiments disclosed herein are also within the scope of this disclosure. The above-described embodiments and additional and/or alternative embodiments of the disclosure will be described in detail hereinafter through reference to the accompanying drawings.
The server(s) 602 and the user device(s) 636 may be configured to communicate via one or more networks 634 which may include, but are not limited to, any one or more different types of communications networks such as, for example, cable networks, public networks (e.g., the Internet), private networks (e.g., frame-relay networks), wireless networks, cellular networks, telephone networks (e.g., a public switched telephone network), or any other suitable private or public packet-switched or circuit-switched networks. Further, the network(s) 634 may have any suitable communication range associated therewith and may include, for example, global networks (e.g., the Internet), metropolitan area networks (MANS), wide area networks (WANs), local area networks (LANs), or personal area networks (PANs). In addition, the network(s) 634 may include communication links and associated networking devices (e.g., link-layer switches, routers, etc.) for transmitting network traffic over any suitable type of medium including, but not limited to, coaxial cable, twisted-pair wire (e.g., twisted-pair copper wire), optical fiber, a hybrid fiber-coaxial (HFC) medium, a microwave medium, a radio frequency communication medium, a satellite communication medium, or any combination thereof.
In an illustrative configuration, the server 602 may include one or more processors (processor(s)) 604, one or more memory devices 606 (generically referred to herein as memory 606), one or more input/output (“I/O”) interface(s) 608, one or more network interfaces 610, and data storage 614. The server 602 may further include one or more buses 612 that functionally couple various components of the server 602. These various components will be described in more detail hereinafter.
The bus(es) 612 may include at least one of a system bus, a memory bus, an address bus, or a message bus, and may permit exchange of information (e.g., data (including computer-executable code), signaling, etc.) between various components of the server 602. The bus(es) 612 may include, without limitation, a memory bus or a memory controller, a peripheral bus, an accelerated graphics port, and so forth. The bus(es) 612 may be associated with any suitable bus architecture including, without limitation, an Industry Standard Architecture (ISA), a Micro Channel Architecture (MCA), an Enhanced ISA (EISA), a Video Electronics Standards Association (VESA) architecture, an Accelerated Graphics Port (AGP) architecture, a Peripheral Component Interconnects (PCI) architecture, a PCI-Express architecture, a Personal Computer Memory Card International Association (PCMCIA) architecture, a Universal Serial Bus (USB) architecture, and so forth.
The memory 606 of the server 602 may include volatile memory (memory that maintains its state when supplied with power) such as random access memory (RAM) and/or non-volatile memory (memory that maintains its state even when not supplied with power) such as read-only memory (ROM), flash memory, ferroelectric RAM (FRAM), and so forth. Persistent data storage, as that term is used herein, may include non-volatile memory. In certain example embodiments, volatile memory may enable faster read/write access than non-volatile memory. However, in certain other example embodiments, certain types of non-volatile memory (e.g., FRAM) may enable faster read/write access than certain types of volatile memory.
In various implementations, the memory 606 may include multiple different types of memory such as various types of static random access memory (SRAM), various types of dynamic random access memory (DRAM), various types of unalterable ROM, and/or writeable variants of ROM such as electrically erasable programmable read-only memory (EEPROM), flash memory, and so forth. The memory 606 may include main memory as well as various forms of cache memory such as instruction cache(s), data cache(s), translation lookaside buffer(s) (TLBs), and so forth. Further, cache memory such as a data cache may be a multi-level cache organized as a hierarchy of one or more cache levels (L1, L2, etc.).
The data storage 614 may include removable storage and/or non-removable storage including, but not limited to, magnetic storage, optical disk storage, and/or tape storage. The data storage 614 may provide non-volatile storage of computer-executable instructions and other data. The memory 606 and the data storage 614, removable and/or non-removable, are examples of computer-readable storage media (CRSM) as that term is used herein.
The data storage 614 may store computer-executable code, instructions, or the like that may be loadable into the memory 606 and executable by the processor(s) 604 to cause the processor(s) 604 to perform or initiate various operations. The data storage 614 may additionally store data that may be copied to memory 606 for use by the processor(s) 604 during the execution of the computer-executable instructions. Moreover, output data generated as a result of execution of the computer-executable instructions by the processor(s) 604 may be stored initially in memory 606, and may ultimately be copied to data storage 614 for non-volatile storage.
More specifically, the data storage 614 may store one or more operating systems (O/S) 616; one or more database management systems (DBMS) 618; and one or more program modules, applications, engines, computer-executable code, scripts, or the like such as, for example, a Siamese CNN 620 (which in turn may include a view-invariant feature representation generation network 622 and an RPN 624) and a parameter estimation algorithm 626. Any of the components depicted as being stored in data storage 614 may include any combination of software, firmware, and/or hardware. The software and/or firmware may include computer-executable code, instructions, or the like that may be loaded into the memory 606 for execution by one or more of the processor(s) 604 to perform any of the operations described earlier in connection with correspondingly named modules.
The data storage 614 may further store various types of data utilized by components of the server 602 such as, for example, any of the data depicted as being stored in the datastore(s) 528. Any data stored in the data storage 614 may be loaded into the memory 606 for use by the processor(s) 604 in executing computer-executable code. In addition, any data stored in the datastore(s) 528 may be accessed via the DBMS 618 and loaded in the memory 606 for use by the processor(s) 604 in executing computer-executable code.
The processor(s) 604 may be configured to access the memory 606 and execute computer-executable instructions loaded therein. For example, the processor(s) 604 may be configured to execute computer-executable instructions of the various program modules, applications, engines, or the like of the server 602 to cause or facilitate various operations to be performed in accordance with one or more embodiments of the disclosure. The processor(s) 604 may include any suitable processing unit capable of accepting data as input, processing the input data in accordance with stored computer-executable instructions, and generating output data. The processor(s) 604 may include any type of suitable processing unit including, but not limited to, a central processing unit, a microprocessor, a Reduced Instruction Set Computer (RISC) microprocessor, a Complex Instruction Set Computer (CISC) microprocessor, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), a System-on-a-Chip (SoC), a digital signal processor (DSP), and so forth. Further, the processor(s) 604 may have any suitable microarchitecture design that includes any number of constituent components such as, for example, registers, multiplexers, arithmetic logic units, cache controllers for controlling read/write operations to cache memory, branch predictors, or the like. The microarchitecture design of the processor(s) 604 may be capable of supporting any of a variety of instruction sets.
Referring now to other illustrative components depicted as being stored in the data storage 614, the O/S 616 may be loaded from the data storage 614 into the memory 606 and may provide an interface between other application software executing on the server 602 and hardware resources of the server 602. More specifically, the O/S 616 may include a set of computer-executable instructions for managing hardware resources of the server 602 and for providing common services to other application programs (e.g., managing memory allocation among various application programs). In certain example embodiments, the O/S 616 may control execution of one or more of the program modules depicted as being stored in the data storage 614. The O/S 616 may include any operating system now known or which may be developed in the future including, but not limited to, any server operating system, any mainframe operating system, or any other proprietary or non-proprietary operating system.
The DBMS 618 may be loaded into the memory 606 and may support functionality for accessing, retrieving, storing, and/or manipulating data stored in the memory 606 and/or data stored in the data storage 614. The DBMS 618 may use any of a variety of database models (e.g., relational model, object model, etc.) and may support any of a variety of query languages. The DBMS 618 may access data represented in one or more data schemas and stored in any suitable data repository.
The datastore(s) 628 may include, but are not limited to, databases (e.g., relational, object-oriented, etc.), file systems, flat files, distributed datastores in which data is stored on more than one node of a computer network, peer-to-peer network datastores, or the like. The datastore(s) 628 may store various types of data such as, for example, depth image data 630 (e.g., the depth image data 102), the 3D keypoint landmark database 632; and so forth.
Referring now to other illustrative components of the server 602, the input/output (I/O) interface(s) 608 may facilitate the receipt of input information by the server 602 from one or more I/O devices as well as the output of information from the server 602 to the one or more I/O devices. The I/O devices may include any of a variety of components such as a display or display screen having a touch surface or touchscreen; an audio output device for producing sound, such as a speaker; an audio capture device, such as a microphone; an image and/or video capture device, such as a camera; a haptic unit; and so forth. Any of these components may be integrated into the server 602 or may be separate. The I/O devices may further include, for example, any number of peripheral devices such as data storage devices, printing devices, and so forth.
The I/O interface(s) 608 may also include an interface for an external peripheral device connection such as universal serial bus (USB), FireWire, Thunderbolt, Ethernet port or other connection protocol that may connect to one or more networks. The I/O interface(s) 608 may also include a connection to one or more antennas to connect to one or more networks via a wireless local area network (WLAN) (such as Wi-Fi) radio, Bluetooth, and/or a wireless network radio, such as a radio capable of communication with a wireless communication network such as a Long Term Evolution (LTE) network, WiMAX network, 3G network, etc.
The server 602 may further include one or more network interfaces 610 via which the server 602 may communicate with any of a variety of other systems, platforms, networks, devices, and so forth. The network interface(s) 610 may enable communication, for example, between the server 602 and the user device 636 via the network(s) 634.
It should be appreciated that the program modules, applications, computer-executable instructions, code, or the like depicted in
It should further be appreciated that the server 602 may include alternate and/or additional hardware, software, or firmware components beyond those described or depicted without departing from the scope of the disclosure. More particularly, it should be appreciated that software, firmware, or hardware components depicted as forming part of the server 602 are merely illustrative and that some components may not be present or additional components may be provided in various embodiments. While various illustrative program modules have been depicted and described as software modules stored in data storage 614, it should be appreciated that functionality described as being supported by the program modules may be enabled by any combination of hardware, software, and/or firmware. It should further be appreciated that each of the above-mentioned modules may, in various embodiments, represent a logical partitioning of supported functionality. This logical partitioning is depicted for ease of explanation of the functionality and may not be representative of the structure of software, hardware, and/or firmware for implementing the functionality. Accordingly, it should be appreciated that functionality described as being provided by a particular module may, in various embodiments, be provided at least in part by one or more other modules. Further, one or more depicted modules may not be present in certain embodiments, while in other embodiments, additional modules not depicted may be present and may support at least a portion of the described functionality and/or additional functionality. Moreover, while certain modules may be depicted and described as sub-modules of another module, in certain embodiments, such modules may be provided as independent modules or as sub-modules of other modules.
One or more operations of any of the methods 200-500 may be performed by a server 602, by a user device 636, or in a distributed fashion by a server 602 and a user device 636, or more specifically, by one or more engines, program modules, applications, or the like executable on such device(s). It should be appreciated, however, that such operations may be implemented in connection with numerous other device configurations.
The operations described and depicted in the illustrative methods of
Although specific embodiments of the disclosure have been described, one of ordinary skill in the art will recognize that numerous other modifications and alternative embodiments are within the scope of the disclosure. For example, any of the functionality and/or processing capabilities described with respect to a particular device or component may be performed by any other device or component. Further, while various illustrative implementations and architectures have been described in accordance with embodiments of the disclosure, one of ordinary skill in the art will appreciate that numerous other modifications to the illustrative implementations and architectures described herein are also within the scope of this disclosure. In addition, it should be appreciated that any operation, element, component, data, or the like described herein as being based on another operation, element, component, data, or the like can be additionally based on one or more other operations, elements, components, data, or the like. Accordingly, the phrase “based on,” or variants thereof, should be interpreted as “based at least in part on.”
Although embodiments have been described in language specific to structural features and/or methodological acts, it is to be understood that the disclosure is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as illustrative forms of implementing the embodiments. Conditional language, such as, among others, “can,” “could,” “might,” or “may,” unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments could include, while other embodiments do not include, certain features, elements, and/or steps. Thus, such conditional language is not generally intended to imply that features, elements, and/or steps are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without user input or prompting, whether these features, elements, and/or steps are included or are to be performed in any particular embodiment.
The present disclosure may be a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present disclosure.
The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.
Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.
Computer readable program instructions for carrying out operations of the present disclosure may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present disclosure.
Aspects of the present disclosure are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.
These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.
The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.
The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.
This application claims the benefit of U.S. Provisional Application No. 62/585,042 filed on Nov. 13, 2017, the content of which is incorporated by reference in its entirety herein.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/US2018/049100 | 8/31/2018 | WO | 00 |
| Number | Date | Country | |
|---|---|---|---|
| 62585042 | Nov 2017 | US |
