SYSTEM, METHOD AND COMPUTER READABLE STORAGE FOR ENABLING AN INSTANTANEOUS INSTRUMENT

Information

  • Patent Application
  • 20240037534
  • Publication Number
    20240037534
  • Date Filed
    October 06, 2023
    7 months ago
  • Date Published
    February 01, 2024
    3 months ago
Abstract
Disclosed are various embodiments for enabling an instantaneous instrument. In various embodiments, a computing device can receive a request to open a virtual card. Various embodiments of the computing device can then generate a card number for the virtual card. The computing device can then transmit the card number to a user device, which can be used as an instantaneous instrument to make purchases. In various embodiments, the computing device can receive an authorization request from a point of sale terminal, where the authorization request includes the card number. In various embodiments, the computing device can generate a statement that indicates that the authorization request corresponds to the virtual card.
Description
BACKGROUND OF THE INVENTION
Field of the Invention

The present general inventive concept is directed to a method, apparatus, and computer readable storage medium directed to method, apparatus, and computer readable storage to implement applying for and receiving an instantaneous virtual card with is then associated with a physical card.


Description of the Related Art

People in need of a financial account (e.g., credit card, debit card, etc.) can apply electronically and receive an instant decision. However, a user may be limited in what the user can do with the account until a physical card arrives in the mail.


SUMMARY OF THE INVENTION

It is an aspect of the present invention to provide an improved instant account system.


These together with other aspects and advantages which will be subsequently apparent, reside in the details of construction and operation as more fully hereinafter described and claimed, reference being had to the accompanying drawings forming a part hereof, wherein like numerals refer to like parts throughout.





BRIEF DESCRIPTION OF THE DRAWINGS

Further features and advantages of the present invention, as well as the structure and operation of various embodiments of the present invention, will become apparent and more readily appreciated from the following description of the preferred embodiments, taken in conjunction with the accompanying drawings of which:



FIG. 1 is a flowchart illustrating an exemplary method for providing an instantaneous virtual card and associating it with a physical card, according to an embodiment;



FIG. 2 is a flowchart illustrating an exemplary method of installing a virtual card on a mobile device, according to an embodiment;



FIG. 3 is a drawing of a virtual card on a mobile device, according to an embodiment;



FIG. 4 is a drawing of a credit card statement combining charges from both the physical and virtual card, according to an embodiment;



FIG. 5 is a block diagram illustrating participants of the system, according to an embodiment;



FIG. 6 is a block diagram illustrating hardware that can be used to implement a computer/device which can implement any and all of the methods described herein.





DESCRIPTION OF THE PREFERRED EMBODIMENTS

Reference will now be made in detail to the presently preferred embodiments of the invention, examples of which are illustrated in the accompanying drawings, wherein like reference numerals refer to like elements throughout.


The present inventive concept relates to a method, apparatus, and computer readable storage medium to implement providing a user with an instant credit card and thereafter associating the instant credit card with a real, physical credit card associated with the same account.


A user (e.g., a consumer) can apply for a virtual card (e.g., a virtual credit card, virtual debit card, etc.) anywhere (e.g., in line at a checkout counter, at home, using a mobile device at any location, etc.). The virtual card can be used just as if it were a real card (e.g., physical credit card, debit card, etc.). The only difference is that the virtual card cannot be swiped since it does not really exist. Instead, the virtual card would have a card number, just as any physical card number would, which can be typed into a computer (or other credit card processor) and used in that manner. The virtual card can be displayed on a personal computing device using an app. A physical card can be mailed (or otherwise delivered) to the user so ultimately the user can use either the physical card or the virtual card to make transactions.



FIG. 1 is a flowchart illustrating an exemplary method for providing an instantaneous virtual card and associating it with a physical card, according to an embodiment.


The method can begin with operation 100, in which a user applies for an instant card. The instant card can be a number of different types of cards, such as a credit card, a debit card, a stored value card, a bitcoin card, or any other such paradigm. Note that as used herein, when the card is a credit card then physical card refers to a physical credit card and virtual card refers to a virtual credit card. When the card is a debit card then physical card refers to a physical debit card and virtual card refers to virtual debit card. When the card is a stored value card then physical card refers to a physical stored value card and virtual card refers to a virtual stored value card. When the card is a bitcoin card, then physical card refers to a physical bitcoin card and virtual card refers to a virtual bitcoin card. “Card” used by itself can refer to both a physical and virtual card.


A credit card can be a VISA®, MASTERCARD®, AMERICAN EXPRESS®, DISCOVER®, or a card which can be accepted at millions of locations worldwide. A transaction with such a card is charged against a credit account owned by the user to which the user should pay off (either immediately or over time along with an interest surcharge).


A debit card is a card in which is associated with a bank account and can also be associated with VISA®, MASTERCARD®, etc., but the money actually is debited out of the user's bank account and no credit is used. A processor would process the transaction using the VISA® or MASTERCARD® infrastructure but instead of the amount being further processed by a credit card the amount is processed by the user's bank (issuer of the debit card) to deduct the respective amount.


A stored value card actually stores any value on the card itself Examples of stored value cards are transit system fare-cards, cafeteria cards, etc. Since the value is stored on the card itself, there is no need for a remote server to query in order to check on the value of the card. Data representing the value on a stored value card would be encrypted and stored on the stored value card. A virtual stored value card would store the same data that would be stored on a physical stored value card but on a computer memory (e.g., flash memory on a mobile phone) where it can be transmitted to a stored value card reader.


A bitcoin card is a card that operates like a VISA®, MASTERCARD®, etc., but the funds are paid from a bitcoin account that is funded in bitcoins. Bitcoins are a well-known cryptocurrency. In this manner, charges made by the card are not paid for in dollars but are taken in bitcoins from the user's account (which can be a bit coin wallet). When a charge is made, the amount bitcoins equivalent to the charge would be automatically sold in order to fund the charge made.


In operation 100, the application for a card (actually an account which will issue a virtual card instantly and a physical card in the near future (such as in 24 hours the physical card can be mailed) can be done in a number of ways. For example, the user can use an internet-connected home computer (or personal computing device such as a cell phone, tablet, smart watch, etc.) and apply online (either using the World Wide Web or using an app). The user can also be at a retail establishment and the cashier can fill out an application for the user (by asking for the user's application information and entering application information into a terminal). The application information is information needed to process the application and render a decision, which comprises the user's name, address, social security number, employer, annual salary, etc.


Note that different types of cards may have a different application process. For example, different types of cards may require different information in the application. A credit card application would require the user to enter his/her income, while a debit card application would typically not need this information.


From operation 100, the method proceeds to operation 101, which processes the application by a processing server. The application information is transmitted to the processing server which retrieves respective information from one or more databases and evaluates the information and renders a decision whether to approve or deny the application.


Each different type of card would have a different evaluation process. For example, if the card being applied for is a credit card, then the user's credit worthiness is evaluated. The processing of the evaluation for a virtual credit card takes a number of data points and uses a weighted average to determine whether or not to approve the credit application. For example, factors such as the user's current salary, current credit score, age, etc., can all be put into a formula which takes a weighted average of each factor and then, if the final result is above a particular threshold, the application is approved otherwise it is denied. Or as another example, if certain factors all meet minimum requirements, then the application is approved otherwise the application is denied. For example, an application must have a credit score of at least 700 and a current income of at least 50,000 and if both of these factors are met then the application is approved, otherwise the application is denied. In addition to an approval/denial, the processing server also determines how much of a credit limit to grant to the user. This can be determined also by a formula. For example, the credit limit can be $1,000+(current income>30,000)*10% with a cap of $10,000. In other words, the minimum credit limit that a user can get is $1,000, a maximum credit limit that a user can get is $10,000 and for every dollar in income the user makes in excess of 30,000 (e.g., user's current income−30,000) the credit line will be increased by $0.10 (i.e., ten cents). So, a user who makes $50,000 will be given a credit line of $1,000+(50,000−30,000)*.10=$3,000.


If the card being applied for is a debit card, then the processing server would evaluate whether the user has a valid and funded bank account to which the virtual debit card can draw from. If the card being applied for is a bitcoin card, then the processing server would evaluate whether the user has an active bitcoin wallet with a minimum value of bitcoins (e.g., $5.00).


In operation 102, if the application is denied, then the method proceeds to operation 104, which rejects the application by presenting the player with a message that his/her application was denied and then the method ends.


If in operation 102, the application is approved, then the method proceeds to operation 103, which issues to the player a virtual card (see FIG. 2 and its accompanying description). The user's personal computing device (e.g., mobile phone, personal computer, tablet, smart watch, etc.) would receive the approval from processing server. The processing server would transmit to the user's computing device all information needed regarding the new virtual card, including such things like the bank name, card number (e.g., credit card number or debit card number), expiration date, CVV number, and any other relevant information. An app can be running on the user's computing device which can “construct” a virtual card (see FIG. 3).


If the virtual card is a virtual credit card, it can now be used like a regular credit card (e.g., it can be a VISA® or MASTERCARD® or other such classification). While the virtual card cannot be swiped because it does not physically exist, nevertheless the credit card number on the virtual card can be used for purchases like any other physical card. They can be typed into order forms, credit card machines, etc., along with the expiration date (and optionally the CVV number) and the transaction will be processed as if the virtual card was a normal card.


The virtual credit card can thus be used at many different merchants (e.g., anywhere VISA®/MASTERCARD® is accepted) and is not limited to being used at a particular store or chain of stores. Compare this to a store card, for example in which one can go to a merchant Acme Tools and apply for an in-store credit account and can receive an Acme Tools credit card subsequently in the mail. However, this Acme Tools credit card can only be used at Acme Tools stores and no other merchant (it is not a VISA® or MASTERCARD®).


If the card is a virtual debit card, it can be used as if it was any standard credit card (accepted wherever VISA®, MASTERCARD®, DISCOVER®, etc. are accepted). The user can present the number on the card (or an app displaying the card) and the card shown can also be used like any credit card (by typing in the number) but the money for each charge is deducted from the user's bank account (as opposed to being applied to a credit account as in the case of a credit card).


If the card is a virtual stored value card, then it can be used as if it was any stored value card. Stored value cards can encrypt information on the card which designated how much value is on the card. Using an app in place of a stored value card would work similarly, but the app would receive (e.g., via a communication device such as Bluetooth, etc.) communications from a stored value kiosk which records the data from the kiosk and can transmit such data when the user wishes to present the virtual stored value card for payment. The app would receive, store, and transmit, and data that would have been stored on a physical stored value card.


If the card is a bitcoin card, then the virtual bitcoin card could be used as any virtual credit card (e.g., by presenting the card number which can be entered into a computer) which functions like a physical bitcoin card (in which the funds are taken from the user's bitcoin wallet).


From operation 103, the method proceeds to operation 105, which issues a physical card to the user. The physical card will have printed on it the same information as the virtual card (e.g., number, name, expiration date, CVV number, etc.) and can be mailed to the user. The physical card can look identical in appearance to how the virtual card would be displayed on the personal computing device.


From operation 105, the method proceeds to operation 106, which associates the virtual card to the physical card. The user can activate the physical card in numerous ways, such as calling a number to confirm the card was received, going to a web site and answering security questions, etc. The account that maintains the virtual card will be updated to reflect that the physical card was mailed to the user and activated. Thus, the virtual card and the physical card will both be linked to the same account. Whether the virtual card or the physical card is used would not matter as the debits would be processed by the same account. Only one statement would be mailed (or transmitted electronically) to the user which would contain transactions from both the physical card and the virtual card.


Thus, the virtual version of the physical card will have the same functionality of the physical card (with the exception that the virtual card cannot be swiped) and the virtual and physical cards can be used interchangeably with no difference in effect.



FIG. 2 is a flowchart illustrating an exemplary method of installing a virtual card on a mobile device, according to an embodiment. This is performed during operation 103 in FIG. 1.


In operation 200, an app that is running on a user's personal computing device is downloaded. This app allows the receiving of encrypted information from the processing server and enables the virtual card to be displayed on the computing device (see FIG. 3).


In operation 201, the processing server will utilize the application information received from the user (e.g., the user's name, address, social security number, etc.) to generate a new record for a new virtual card.


From operation 201, the method proceeds to operation 202, wherein the processing server will generate a new and unique card number. This is the number that is used when a charge is made to identify the card and is printed on physical cards themselves. For example, in the case of a credit card, the unique card number is the credit card number that is typically printed on the face of the physical credit card (and also displayed on the virtual credit card as well). The processing server can also generate a CVV code (a three-digit code which can be required during a transaction as an extra level of security), an expiration date, and any other data which is needed to generate a new physical card. Different types of cards would require different types of attributes (for example, a stored value card may not need a CVV code).


From operation 202, the method proceeds to operation 203, which transmits the unique card number generated in operation 202 to the app running on the mobile device. The app can then use this information and generate an image of the virtual card on the mobile device (See FIG. 3).



FIG. 3 is a drawing of a virtual card on a mobile device, according to an embodiment.


A personal computing device 300 (in this case a tablet) is running an app which displays an image of a virtual credit card. The image will look like a standard credit card, complete with bank logo, credit card number, expiration date, etc. While FIG. 3 shows an example of a virtual credit card, the other types of cards (e.g., debit card, stored value card, bitcoin card, etc.) would be displayed and utilized similarly. While FIG. 3 displays a virtual credit card, a virtual debit card, virtual stored value card, virtual bitcoin card would be displayed similarly (showing any information that the respective type of card would have on its face).


The app can mimic a chip card (or EMV card) and handle all communications that a chip card would process, using input/output protocols such as Bluetooth, Wi-Fi, RFID, etc. A chip card encrypts information and transmits it to the terminal and vice versa, thus verifying the authenticity of the chip card and also maintaining the privacy of the card number (e.g., credit card number for a credit card, debit card number for a debit card, etc.). The app running on the personal computing device can implement the virtual card which can work with these terminals in the same manner that the physical card would handle such a transaction (assuming the terminal has a sufficient method of communications (e.g., Wi-Fi, RFID, Bluetooth, tee.) to communicate with the app running on the personal computing device since of course the personal computing device cannot be inserted into the terminal as would a standard physical chip card.



FIG. 4 is a drawing of a credit card statement combining charges from both the physical and virtual credit card, according to an embodiment. The statement can be printed on paper or electronically displayed on an electronic output device. Note that while FIG. 4 illustrates a credit card account (utilizing a virtual card and a physical card), such a statement can be generated for any other type of card (e.g., debit card, stored value card, bitcoin card, etc.) with the transactions from both the virtual and physical cards merged.


Note that the example statement 401 looks like a standard credit card statement, with the only difference being the last column shows whether the charge shown was incurred via the virtual card or the physical card. When the physical card is presented to a merchant then it would be labeled as “physical” while when a purchase is made using the app or just by utilizing the credit card number (e.g., ordering online) then it would be labeled as “virtual.”



FIG. 5 is a block diagram illustrating participants of the system, according to an embodiment.


Processing server 500 is used to receive new card applications (see operation 101) and process them by evaluating the information in the application and determining whether the applicant is a good risk (in which the application is accepted) or an unworthy risk (in which the application is rejected). The decision is typically determined and communicated to the applicant (and other involved parties) by the processing server 500 instantaneously. Point of sale terminal 501 is where a user can make an application for a virtual card (see operation 100). Point of sale terminal 501 is also where the user can use his physical credit card and/or his/her virtual card. Remote users 503, 504 can also apply for the virtual card remotely (as opposed to in person at a point of sale terminal 501) on their personal computing device (the application of which is then transmitted to the processing server 500). Authorization server 502 is a server which receives card authorization requests and either approves or declines them based on whether the card number used is valid and there are adequate funds left on that card. When a user makes a purchase using their card (e.g., credit card), whether it be physical or virtual, at a point of sale terminal 501 or online (e.g., a purchase from AMAZON.COM®) an authorization request is transmitted to the authorization server 502 (there can be many such servers operating simultaneously) to approve or deny such request. If the authorization request is denied, then any transaction contingent upon such approval will not be processed. If the authorization request is approved, then the transaction can be completed. The remote users 503, 504 will also receive their statements (e.g., monthly) from a bank server 505 which administers the card account. When the authorization server 502 is queried whether to approve a transaction or not it may have to be routed to the bank server 505 which would then make the final determination of whether the credit authorization (which includes an amount of the requested purchase) should be approved or not. The bank server 505 may have access to information that the authorization server 502 may not, such as the value of bank accounts or how much credit is left on a credit account.


In the case of a credit card, an authorization would be approved if the account associated with the credit card is in good standing (not past due) and the available credit on the credit card account is greater (or greater than equal) to the amount of the requested purchase, otherwise the authorization request would be denied. In the case of a debit card, an authorization would be approved if the account associated with the debit card is in good standing and has sufficient funds to cover the purchase amount (embedded in the authorization request). In the case of a stored value card, typically the authorization server 502 would not be required as a stored value card would not need to be authorized by an outside entity. In the case of a bitcoin card, the authorization request would be approved if the dollar value of the bitcoins in the associated bitcoin wallet is greater than or equal to the amount of the authorization request.



FIG. 6 is a block diagram illustrating hardware that can be used to implement a computer/device which can implement any and all of the methods described herein. The computer can be the platform, any server, personal computing device, cell phones, or any electronic device used as part of the system. Any and all of the methods described herein can be installed as software on the device.


A processing unit 600 (such as a microprocessor and any associated components) is connected to an output device 601 (such as an LCD monitor, touch screen, CRT, etc.) which is used to display to the user any aspect of all methods described herein (including any values described herein), and an input device 602 (e.g., buttons, a touch screen, a keyboard, mouse, etc.) which can be used to input from the user any input needed by any feature described herein. All methods and features described herein can be performed by the processing unit 600 by loading and executing respective instructions. The processing unit 600 can also be connected to a network connection 603, which can connect the processing unit 600 to a computer communications network such as the Internet, a LAN, WAN, etc. and transmit/receive all data (whether described herein or not). The processing unit 600 is also connected to a RAM 604 and a ROM 605. The processing unit 600 is also connected to a storage device 606 which can be a DVD-drive, CD-ROM, flash memory, etc. Multiple such processing units can also work in collaboration with each other (in a same or different physical location). A non-transitory computer readable storage medium 607 can store a program which can control the electronic device to perform any of the methods described herein and can be read by the storage device 606.


While one processing unit (or device/computer) is shown, it can be appreciated that one or more such processor/computer can work together (either in a same physical location or in different locations) to combine to implement any of the methods described herein. Programs and/or data required to implement any of the methods/features described herein can all be stored on any non-transitory computer readable storage medium (volatile or non-volatile, such as CD-ROM, RAM, ROM, EPROM, microprocessor cache, etc.) which can then be executed by one or more processing units.


All components of the system (e.g., platform, servers, computers, databases, etc.) can communicate with each other using a computer communication network (e.g., the internet) in order to exchange data as needed by the method.


Any description of a component or embodiment herein also includes hardware, software, and configurations which already exist in the prior art and may be necessary to the operation of such component(s) or embodiment(s).


Further, the operations described herein can be performed in any sensible order. Any operations not required for proper operation can be optional. Further, all methods described herein can also be stored on a (non-transitory) computer readable storage medium to control a computer. Programs and/or data required to implement any of the methods/features described herein can all be stored (and executed therefrom to perform any of the methods/features) on any non-transitory computer readable storage medium (volatile or non-volatile, such as CD-ROM, RAM, ROM, EPROM, microprocessor cache, etc.).


The many features and advantages of the invention are apparent from the detailed specification and, thus, it is intended by the appended claims to cover all such features and advantages of the invention that fall within the true spirit and scope of the invention. Further, since numerous modifications and changes will readily occur to those skilled in the art, it is not desired to limit the invention to the exact construction and operation illustrated and described, and accordingly all suitable modifications and equivalents may be resorted to, falling within the scope of the invention.

Claims
  • 1. A method comprising: receiving, by a computing device, a first request to open an instantaneous instrument;generating, by the computing device, an instrument number for the instantaneous instrument;transmitting, by the computing device, the instrument number to a client device;receiving, by the computing device and from a terminal, a second request comprising the instrument number; andgenerating, by the computing device, a statement that indicates at least in part that the second request corresponds to the instantaneous instrument.
  • 2. The method of claim 1, further comprising: generating, by the computing device, a security code that corresponds to the instrument number; andsending, by the computing device, instructions to print the physical card, wherein the instrument number and the security code are displayed on a surface of the physical instrument as a result of printing the physical instrument.
  • 3. The method of claim 2, wherein the statement further indicates at least in part that a third request corresponds to the physical instrument, the third request comprising the instrument number.
  • 4. The method of claim 1, wherein the first request comprises user information and the method further comprises evaluating, by the computing device and in response to receiving the first request, the first request to determine that the user information satisfies each requirement of a set of minimum requirements to open the instantaneous instrument.
  • 5. The method of claim 1, wherein the first request comprises user information and the method further comprising: assigning, by the computing device, each portion of the user information a score to generate a set of scores;averaging, by the computing device, each score in the set of scores to calculate an evaluation score;comparing, by the computing device, the evaluation score to a threshold value.
  • 6. The method of claim 5, further comprising applying, by the computing device and prior to averaging each score in the set of scores to calculate the evaluation score, a weight to a first score in the set of scores.
  • 7. The method of claim 1, further comprising transmitting, by the computing device and to the client device, encrypted information about the instantaneous instrument.
  • 8. A system, comprising: a computing device comprising a processor and a memory; andmachine-readable instructions stored in the memory that, when executed by the processor, cause the computing device to at least: receive a first request to open an instantaneous instrument;generate an instrument number for the instantaneous instrument;transmit the instrument number to a client device;receive, from a terminal, a second request comprising the instrument number; andgenerate a statement that indicates at least in part that the second request corresponds to the instantaneous instrument.
  • 9. The system of claim 8, wherein the machine-readable instructions further cause the computing device to at least: generate a security code that corresponds to the instrument number; andprint a physical instrument, wherein the instrument number and the security code are displayed on a surface of the physical instrument as a result of printing the physical instrument.
  • 10. The system of claim 9, wherein the statement further indicates at least in part that a third request corresponds to the physical instrument, the third request comprising the instrument number.
  • 11. The system of claim 8, wherein the first request comprises user information and the machine-readable instructions further cause the computing device to at least evaluate, in response to receiving the first request, the first request to determine that the user information satisfies each requirement of a set of minimum requirements to open the instantaneous instrument.
  • 12. The system of claim 8, wherein the first request comprises user information and the machine-readable instructions further cause the computing device to at least: assign each portion of the user information a score to generate a set of scores;average each score in the set of scores to calculate an evaluation score;compare the evaluation score to a threshold value.
  • 13. The system of claim 12, wherein the machine-readable instructions further cause the computing device to at least apply, prior to averaging each score in the set of scores to calculate the evaluation score, a weight to a first score in the set of scores.
  • 14. The system of claim 8, wherein the machine-readable instructions further cause the computing device to at least transmit, to the client device, encrypted information about the instantaneous instrument.
  • 15. A non-transitory, computer-readable medium, comprising machine-readable instructions that, when executed by a processor of a computing device, cause the computing device to at least: receive a first request to open an instantaneous instrument;generate an instrument number for the instantaneous instrument;transmit the instrument number to a client device;receive, from a terminal, a second request comprising the instrument number; andgenerate a statement that indicates at least in part that the second request corresponds to the instantaneous instrument.
  • 16. The non-transitory, computer-readable medium of claim 15, wherein the machine-readable instructions, when executed by the processor, further cause the computing device to at least: generate a security code that corresponds to the instrument number; andprint a physical instrument, wherein the instrument number and the security code are displayed on a surface of the physical instrument as a result of printing the physical instrument.
  • 17. The non-transitory, computer-readable medium of claim 16, wherein the statement further indicates at least in part that a third request corresponds to the physical instrument, the third request comprising the instrument number.
  • 18. The non-transitory, computer-readable medium of claim 15, wherein the first request comprises user information and the machine-readable instructions further cause the computing device to at least evaluate, in response to receiving the first request, the first request to determine that the user information satisfies each requirement of a set of minimum requirements to open the instantaneous instrument.
  • 19. The non-transitory, computer-readable medium of claim 15, wherein the first request comprises user information and the machine-readable instructions further cause the computing device to at least: assign each portion of the user information a score to generate a set of scores;average each score in the set of scores to calculate an evaluation score;compare the evaluation score to a threshold value.
  • 20. The non-transitory, computer-readable medium of claim 19, wherein the machine-readable instructions further cause the computing device to at least apply, prior to averaging each score in the set of scores to calculate the evaluation score, a weight to a first score in the set of scores.
CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of, and claims priority to and the benefit of, copending U.S. patent application Ser. No. 14/991,888, entitled “SYSTEM, METHOD AND COMPUTER READABLE STORAGE FOR ENABLING AN INSTANTANEOUS INSTRUMENT” and filed on Jan. 8, 2016, which is incorporated by reference as if set forth herein in its entirety.

Continuations (1)
Number Date Country
Parent 14991888 Jan 2016 US
Child 18482420 US