Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
CROSS-REFERENCE TO RELATED APPLICATIONS
This application is a continuation of U.S. patent application Ser. No. 17/109,584, filed Dec. 2, 2020, the complete disclosure of which is incorporated herein by reference in its entirety.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 09/24/2024 was filed along with the mailing date of the Non-Provisional Patent Application on 09/24/2024. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
DETAILED ACTION
This Office Action is in response to a Non-Provisional Patent Application received on 09/23/2024. In the Application, claims 1-20 have been received for consideration and have been examined.
Specification
Applicant’s submitted specification has been reviewed and found to be in compliance.
Drawings
Applicant’s submitted drawings have been reviewed and found to be in compliance.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. US12126625B2.
Although the claims at issue are not identical, they are not patentably distinct from each other because the claim discloses similar subject matter which involves implementing a method and system comprising monitoring a data stream comprising a plurality of data events; identifying a data pattern comprising one or more of the plurality of data events; determining that at least one of the data events comprising the data pattern supports virtual card generation; determining that the at least one of the data events comprising the data pattern is performed using a physical card number at a geolocation; determining that at least one virtual number has been associated with profile data associated with a user; transmitting a notification comprising a request to generate a virtual number; and upon receipt of an approval of the request, executing a script to generate the virtual number and associate the virtual number with the geolocation.
Claims 1-20 recite similar limitations as claims of US Patent no. US12126625B2 as
follows:
Instant Application # 18/894,063
US Patent No. US US12126625B2
1. A system for data security, comprising:
a processor;
a memory storing instructions executable by the processor;
a web browser extension installed on a user device associated with a user and comprising one or more software modules configured to execute a script; and
a database containing profile data associated with a user accessible by the processor,
wherein the processor is configured to execute the instructions to:
determine that a monitored data event from a data stream comprises a data pattern that supports virtual card generation,
determine that the monitored data event is use of a physical card number at a geolocation,
receive, via an application programming interface (API) of the processor, from a web browser extension on a web browser installed on the user device, an inquiry whether a notification comprising a request to generate a virtual number is to be sent to a mobile device associated with the user,
upon a positive answer to the inquiry, transmit the notification comprising the request to generate a virtual number to the mobile device, the notification being transmitted from the web browser extension to the mobile device, and
upon receipt of an approval of the request, execute, by the web browser extension, the script to:
generate the virtual number, and
associate the virtual number with the geolocation.
1. A system for data security, comprising:
a processor;
a memory storing instructions executable by the processor;
a web browser extension installed on a user device used by the user and comprising one or more software modules configured to execute a script; and
a database containing profile data associated with a user accessible by the processor,
wherein the processor is configured to execute the instructions to:
deploy the web browser extension on a web browser installed on the user device used by the user,
monitor a data stream comprising a plurality of data events,
identify a data pattern comprising one or more of the plurality of data events,
determine that at least one of the data events comprising the data pattern supports virtual card generation,
determine that the at least one of the data events comprising the data pattern is performed using a physical card number at a geolocation,
determine, by accessing the profile data, that at least one old virtual number has been associated with the profile data, wherein the association of the at least one old virtual number with the profile data includes that the at least one old virtual number has been deleted in the past,
receive, via an application programming interface (API) of the processor, from the web browser extension on the web browser installed on the user device used by the user, an inquiry whether a notification comprising a request to generate a virtual number will be sent to a mobile device used by the user,
in response to a positive answer to the inquiry, transmit the notification comprising the request to generate a virtual number to the mobile device used by the user, the notification being transmitted from the web browser extension to the mobile device used by the user, and
upon receipt of an approval of the request, execute, by the web browser extension, the script to:
generate the virtual number, wherein generating the virtual number includes retrieving one of the at least one old virtual number, and
associate the virtual number with the geolocation.
The table above shows that claim 1 of an instant application recite similar limitations in a broader concept as a computer platform claim presented in the patent publication, and therefore are rejected under the same rationale. It would have been obvious to one of the ordinary person skills in the art to build a system or a computer program product, provided with corresponding method.
Other Independent and Dependent claims in instant application recite similar concept as mentioned in the patent publication.
Although the conflicting claims are not identical, they are not patentably distinct from each other because the claims in the instant application are anticipated by the claims in US Patent no. US12126625B2.
Furthermore, there is no apparent reason why applicant was prevented from presenting claims corresponding to those of the instant application during prosecution of the application which matured into a patent. See In re Schneller, 397 F.2d 350, 158 USPQ 210 (CCPA 1968). See also MPEP § 804.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2 and 4-20 are rejected under 35 U.S.C. 103 as being unpatentable over Wu et al., (US10296897B1) in view of Amor et al., (US20200005317A1).
Regarding claim 1, Wu discloses:
A system for data security, comprising:
a processor;
a memory storing instructions executable by the processor;
a web browser extension (i.e., browser extension) installed on a user device associated with a user and comprising one or more software modules configured to execute a script (Col. 1, Line # 42-44; FIG. 4 is a flow diagram illustrating a process used in some implementations for creating a ghost card via a browser extension; Col. 6, Line # 11-15; discloses a “Website detection module 346” which discloses detecting user’s pattern of browsing by detecting user accessing a particular category of websites for which the user previously used the browser extension; Col. 8, Line # 10-11; FIG. 4 is a flow diagram illustrating a set of operations 400 for creating a ghost card via a browser extension. Detecting operation 402 detects that the user is accessing a retailer or service provider website. Enabling operation 404 enables an interactive window or icon that can provide information as requested);
and a database containing profile data associated with a user accessible by the processor (Col. 6, line # 25-29; “Information module 348” discloses comprising user information such as user account info and account balances), wherein the processor is configured to execute the instructions to:
determine that a monitored data event from a data stream comprises a data pattern that supports virtual card generation (Col. 6, Line # 11-15; discloses a “Website detection module 346” which discloses detecting user’s pattern of browsing by detecting particular category of websites for which the user previously used the browser extension; Col. 8, Line # 15-17; Detecting operation 406 detects that the user is accessing a payment webpage of the retailer or service provider),
determine that the monitored data event is use of a physical card number i.e., actual account number which is presented as payment instrument in FIG. 4) at a geolocation (i.e., performing online purchase at the website of the merchant as depicted in FIG. 6) (Col. 8, Line # 17-23; discloses generating operation 408 which generates a list of payment instruments associated with the user. The list can be displayed in the interactive window or via a separate window or icon. Receiving operation 410 receives a selection of a payment instrument. Creating operation 412 creates an electronic ghost card and linking operation 414 links the electronic ghost card with the selected payment instrument.
Examiner would like to note that instant specification paragraph [0043] defines the term “geolocation” which includes non-physical merchant locations (e.g., websites, online commerce platforms etc. which is equivalent to Wu’s merchant website at which the user is trying to make a purchase and due to that ghost card [virtual card] is being generated by the system through the web browser extension),
receive, via an application programming interface (API) (i.e., ghost card creation platform 164/Ghost card creation module 352) of the processor, from a web browser extension on a web browser installed on the user device, an inquiry whether a notification comprising a request to generate a virtual number is to be sent to a mobile device associated with the user (Col. 4, Line # 32-34; Memory 150 can include program memory 160 that stores programs and software, such as an operating system 162, ghost card creation platform 164; Col. 6, Line # 58-67; Ghost card creation module 352 can create an electronic ghost card upon receiving a selection of a payment instrument with which to link the ghost card. The electronic ghost card can be a temporary payment mechanism linked to a user's payment card to anonymize the user's actual payment card information. The ghost card can include randomly generated numbers to insert into a payment webpage of a retailer or service provider website, including a credit or debit card number, CVV (or similar verification number), and expiration date; Col. 9, Line # 14-17; discloses in FIG. 12 which depicts an example of a user interface where the browser extension includes a selectable button near the card input field for the user to generate a ghost card number (“generate number” button)),
upon a positive answer to the inquiry, transmit the notification comprising the request to generate a virtual number to the mobile device, the notification being transmitted from the web browser extension to the mobile device (Col. 6, Line # 67 – Col. 7, Line # 1-2; Ghost card creation module creates the electronic ghost card and associates the electronic ghost card with the selected payment instrument of the user), and
upon receipt of an approval of the request, execute, by the web browser extension, the script to:
generate the virtual number, and associate the virtual number with the geolocation (i.e., performing online purchase at the website of the merchant as depicted in FIG. 6) (Col. 8, Line # 17-23; Generating operation 408 generates a list of payment instruments associated with the user. The list can be displayed in the interactive window or via a separate window or icon. Receiving operation 410 receives a selection of a payment instrument. Creating operation 412 creates an electronic ghost card and linking operation 414 links the electronic ghost card with the selected payment instrument).
Wu fails to disclose:
determining, by accessing the profile data, that at least one virtual number has been associated with the profile data.
However, Amor discloses:
determining, by accessing the profile data, that at least one virtual number has been associated with the profile data ([0089] According to some embodiments, next in operation 730, the system 10 is checking if the new virtual credit card number already exists in the data storage device 20 meaning, if the virtual number is in use or was in use in a predefined period of time. In case, the credit card number exists, or the virtual credit card number was in use in a predetermined period of time).
It would have been obvious to an ordinary person skilled in the art before the effective filing date of the claimed invention to modify the Wu reference and include a system which contains a database which stores virtual credit card information which links to the real/physical credit card number, as disclosed by Amor.
The motivation to include such a system is to ensure and verify if the virtual credit card information matches with the real/physical credit card number when a user presents the virtual credit card information for any transactions.
Regarding claim 14, it is a method claim and recites similar subject matter as claim 1 and therefore rejected under similar ground of rejection.
Regarding claim 20, it is a non-transitory compute-accessible medium claim and recites similar subject matter as claim 1 and therefore rejected under similar ground of rejection.
Regarding claim 2, the combination of Wu and Amor discloses:
The system of claim 1, further comprising the processor being further configured to execute the instructions to:
deploy the web browser extension on a web browser installed on the user device (Wu: Col. 6, Line # 11-15; discloses a “Website detection module 346” which discloses detecting user’s pattern of browsing by detecting user accessing a particular category of websites for which the user previously used the browser extension; Col. 8, Line # 10-11; FIG. 4 is a flow diagram illustrating a set of operations 400 for creating a ghost card via a browser extension),
monitor the data stream resulting in the monitored data event, wherein the data stream comprises a plurality of data events (Wu: Col. 6, Line # 11-15; discloses a “Website detection module 346” which discloses detecting user’s pattern of browsing by detecting particular category of websites for which the user previously used the browser extension; Col. 8, Line # 15-17; Detecting operation 406 detects that the user is accessing a payment webpage of the retailer or service provider), and
identify the data pattern comprising one or more of the plurality of data events (Wu: Col. 8, Line # 17-20; Generating operation 408 generates a list of payment instruments associated with the user. The list can be displayed in the interactive window or via a separate window or icon).
Regarding claim 4, the combination of Wu and Amor discloses:
The system of claim 1, wherein supporting virtual card generation comprises performing the monitored data event being no presentation of the physical card number to the geolocation (Wu: Col. 8, Line # 10-23; FIG. 4 is a flow diagram illustrating a set of operations 400 for creating a ghost card via a browser extension. Detecting operation 402 detects that the user is accessing a retailer or service provider website. Enabling operation 404 enables an interactive window or icon that can provide information as requested. Detecting operation 406 detects that the user is accessing a payment webpage of the retailer or service provider. Generating operation 408 generates a list of payment instruments associated with the user. The list can be displayed in the interactive window or via a separate window or icon. Receiving operation 410 receives a selection of a payment instrument. Creating operation 412 creates an electronic ghost card and linking operation 414 links the electronic ghost card with the selected payment instrument).
Regarding claim 5, the combination of Wu and Amor discloses:
The system of claim 1, wherein the profile data comprises an association of at least one old virtual number with the profile data and further includes at least one of (1) the at least one old virtual number has been used in the past, and (2) the at least one old virtual number has been created in the past (Amor: [0089] According to some embodiments, next in operation 730, the system 10 is checking if the new virtual credit card number already exists in the data storage device 20 meaning, if the virtual number is in use or was in use in a predefined period of time. In case, the credit card number exists, or the virtual credit card number was in use in a predetermined period of time, the system 10 is repeating operation 720 and generating a new number and later operation 730 until the result is that the virtual credit card number does not exist in system 10. If the virtual credit card number does not exist in system 10, operation 740 includes linking the virtual credit card number to the real credit card details and next operation 750 includes saving the virtual credit card number in the database, i.e., data storage device 20 that is connected to the servers 24).
It would have been obvious to an ordinary person skilled in the art before the effective filing date of the claimed invention to modify the Wu reference and include a system which contains a database which stores virtual credit card information which links to the real/physical credit card number, as disclosed by Amor.
The motivation to include such a system is to ensure and verify if the virtual credit card information matches with the real/physical credit card number when a user presents the virtual credit card information for any transactions.
Regarding claim 6, the combination of Wu and Amor discloses:
The system of claim 5, wherein generating the virtual number includes retrieving the at least one old virtual number (Amor: [0089] According to some embodiments, next in operation 730, the system 10 is checking if the new virtual credit card number already exists in the data storage device 20 meaning, if the virtual number is in use or was in use in a predefined period of time. In case, the credit card number exists, or the virtual credit card number was in use in a predetermined period of time, the system 10 is repeating operation 720 and generating a new number and later operation 730 until the result is that the virtual credit card number does not exist in system 10. If the virtual credit card number does not exist in system 10, operation 740 includes linking the virtual credit card number to the real credit card details and next operation 750 includes saving the virtual credit card number in the database, i.e., data storage device 20 that is connected to the servers 24).
It would have been obvious to an ordinary person skilled in the art before the effective filing date of the claimed invention to modify the Wu reference and include a system which contains a database which stores virtual credit card information which links to the real/physical credit card number, as disclosed by Amor.
The motivation to include such a system is to ensure and verify if the virtual credit card information matches with the real/physical credit card number when a user presents the virtual credit card information for any transactions.
Regarding claim 7, the combination of Wu and Amor discloses:
The system of claim 6, wherein the virtual number that is generated is the least one old virtual number with at least one of a different security information or expiration date ([0087] According to some embodiments, method 600 b retrieves the CVV during the user's purchase. Operation 650 includes receiving CVV related password from the user. In operation 660 reading from the database 20 N value. Operation 670 includes calculating the real CVV with P and N, f(P,N)=RCVV. In operation 680 sending the real CVV (RCVV) to the linker at the purchase process with all other credit card details; [0088] FIG. 7 is illustrating generation of a new virtual credit card number, in accordance with some embodiments of the present disclosure. According to some embodiments, before a virtual credit card number is generated, in operation 710, the system 10 is receiving from a user the following parameters: total amount limitation; expiration date; one-time or multiple-time usage; specific days limitation; specific hours limitation; specific dates limitation; credit card details that will be linked to the generated virtual credit card; specific payment-receiver limitation and the like).
It would have been obvious to an ordinary person skilled in the art before the effective filing date of the claimed invention to modify the Wu reference and include a system which contains a database which stores virtual credit card information which links to the real/physical credit card number, as disclosed by Amor.
The motivation to include such a system is to ensure and verify if the virtual credit card information matches with the real/physical credit card number when a user presents the virtual credit card information for any transactions.
Regarding claim 8, the combination of Wu and Amor discloses:
The system of claim 1, wherein the virtual number is only used for the monitored data event (Wu: Abstract & Claim 1, third limitation).
Regarding claim 15, it is a method claim and recites similar subject matter as claim 8 and therefore rejected under similar ground of rejection.
Regarding claim 9, the combination of Wu and Amor discloses:
The system of claim 1, wherein the virtual number is a new virtual number generated by executing the script ([0089] According to some embodiments, next in operation 730, the system 10 is checking if the new virtual credit card number already exists in the data storage device 20 meaning, if the virtual number is in use or was in use in a predefined period of time. In case, the credit card number exists, or the virtual credit card number was in use in a predetermined period of time).
It would have been obvious to an ordinary person skilled in the art before the effective filing date of the claimed invention to modify the Wu reference and include a system which contains a database which stores virtual credit card information which links to the real/physical credit card number, as disclosed by Amor.
The motivation to include such a system is to ensure and verify if the virtual credit card information matches with the real/physical credit card number when a user presents the virtual credit card information for any transactions.
Regarding claim 10, the combination of Wu and Amor discloses:
The system of claim 1, wherein the notification is a push notification transmitted from the web browser extension (Wu: Col. 9, Line # 14-17).
Regarding claim 11, the combination of Wu and Amor discloses:
The system of claim 1, wherein:
the script is registered with a web site associated with an entity, and the entity is associated with the geolocation (Wu: Abstract & Claim 1, third limitation).
Regarding claim 12, the combination of Wu and Amor discloses:
The system of claim 1, wherein the virtual number is generated by the web browser extension (Wu: Col. 8, Line # 10-12)..
Regarding claim 13, the combination of Wu and Amor discloses:
The system of claim 1, wherein the virtual number is used only for a specified number of geolocations (Wu: Abstract & Claim 1, third limitation).
Regarding claim 16, the combination of Wu and Amor discloses:
The method of claim 14, wherein at least one of the data events in the data stream is performed in a web browser of the geolocation (Wu: Col. 8, Line # 17-23; Generating operation 408 generates a list of payment instruments associated with the user. The list can be displayed in the interactive window or via a separate window or icon. Receiving operation 410 receives a selection of a payment instrument. Creating operation 412 creates an electronic ghost card and linking operation 414 links the electronic ghost card with the selected payment instrument).
Regarding claim 17, the combination of Wu and Amor discloses:
The method of claim 13, wherein the notification is a push notification transmitted to the user from a mobile application (Wu: Col. 9, Line # 14-17).
Regarding claim 18, the combination of Wu and Amor discloses:
The method of claim 14, wherein at least one of the data events in the data stream is a data event that is performed by the user without presenting a physical card to the geolocation (Wu: Col. 8, Line # 10-28).
Regarding claim 19, the combination of Wu and Amor discloses:
The method of claim 14, further comprising:
determining, by the processor, whether the geolocation has the script created for putting the virtual number on file at the geolocation (Wu: Col. 8, Line # 10-28).
Claim 3 rejected under 35 U.S.C. 103 as being unpatentable over Wu et al., (US10296897B1) in view of Amor et al., (US20200005317A1) and further in view Prabhu et al., (US20180285860A1).
Regarding claim 3, the combination of Wu and Amor fails to disclose:
The system of claim 1, wherein the processor is further configured to execute the instructions to: determine, by accessing the profile data, whether the profile data includes data indicative of opting in a virtual card creation program.
However, Prabhu discloses:
determine, by accessing the profile data, whether the profile data includes data indicative of opting in a virtual card creation program (i.e., payment vehicle creation program) ([0063-0064] discloses a payment vehicle which is interpreted as virtual card creation program which is used at a time of sale to consumer whose shopping profile conforms to the predetermined shopping profile. The payment vehicle give user an option to generate a virtual card; [0071] As illustrated in FIG. 3A, the consumer may select an option of “Apply for a virtual card now” at a payment screen of the electronic purchase medium, herein represented by an e-commerce platform. The “Apply for a virtual card now” option is an example of the payment vehicle creation mark which may be selected as a payment option; [0074] Once the form is completed and the consumer has selected the desired virtual card type, the virtual card is presented to the consumer as shown in FIG. 3C. The virtual card comprises at least a Primary Account Number (PAN), a Card Verification Code (CVC2) and Expiry date as shown. This information would be required by the consumer to complete his/her purchase. In various embodiments, the virtual card is automatically saved into the consumer account (or into a digital wallet) and placed as the default preferred payment option. The consumer may also choose to change or delete the virtual card after use).
It would have been obvious to an ordinary skill in the art before the effective filing date of the claimed invention to modify the Wu and Amor references and include a payment vehicle program which gives option to user to generate virtual cards, as disclosed by Prabhu.
The motivation to include a payment vehicle program which gives option to the user to generate virtual card is to increase security in the transaction by generating a virtual card when the user is about to conduct the transaction.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SYED M AHSAN whose telephone number is (571)272-5018. The examiner can normally be reached 8:30 AM - 6:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, William Korzuch can be reached at (571) 272-7589. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SYED M AHSAN/Primary Examiner, Art Unit 2491