DETAILED ACTION
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 .
This Office Action is in response to the Applicant’s Amendment filed May 20, 2026. Claims 1-4, 6-11, 13-19, 22-24, and 27 are pending in this case. Claims 5, 12, 20-21, and 25-26 were previously canceled. Claims 1-4, 6-7, 9-11, 13-17, 19, 22-24, and 27 are currently amended.
Response to Arguments
Applicant's arguments filed May 20, 2026, have been fully considered, and upon further search and consideration, have been found not persuasive.
Applicant argues, regarding claims 1, 9, and 15, as currently amended, that nothing in the cited references teaches, discloses, or suggests “wherein the plurality of validity rules include: a maximum transaction amount, a maximum number of transactions, a restriction that limits usability of the temporary payment card to the merchant, and an expiration time that is distinct from the expiration date”.
Examiner respectfully disagrees.
Attention is directed to Mogollon at par 43 “IP addresses associated with the user computing device, number of password attempts, number of username attempts, correct password, time of day, country code associated with data transmission, and/or correct username”, par 47 “DSC is only valid with the particular transaction account for a limited period of time” (expiration time that is distinct from expiration date), par 79 “transaction account issuer 140 may determine that the time received of authorization request is not within a specified amount of the time received of request”.
Sandstrom discloses, as Mogollon does not, and in analogous art, indicating a plurality of validity rules that restrict a usability of the temporary payment card information, wherein the plurality of validity rules include a plurality of validity criteria to be satisfied prior to approval of the transaction, and wherein the plurality of validity criteria includes at least one of: a maximum transaction amount, a maximum number of transactions, a restriction that limits usability of the temporary payment card to the merchant, or an expiration time. (par 5 “validating the time-limited number for the transaction based on the digits indicating the expiration date . . ..”, par 58 “allocate 50,000 of the available numbers to be used as single-use payment card numbers . . . If the number has not been involved in a previous transaction, the financial institution authorizes the current transaction and removes the number from the list of usable numbers. Otherwise, the transaction is rejected . . .” where single use is a validity rule/criterion which is satisfied then the number has not been previously used, also par 31-33 “user device 12 (FIG. 1) transmits information capable of identifying the user, other than information corresponding to the user's payment card number, along with the time-limited number. The other information could be a device signature, such as a service-subscriber or international mobile subscriber identity (“IMSI”). . . . financial institution software normalizes the date on which the payment card transaction was effected to 00:00:00 GMT in a manner identical to that described above with respect to step 114. At step 144, the financial institution software calculates the number of days between the normalized transaction-effected date and the payment card's expiration date. At step 146, the software extracts the last five digits of the PAN of the alternate number and, at step 148, compares the extracted digits to the number of days determined at step 144. If the number of days calculated at step 144 is less than the extracted five digits, this indicates that the alternate, time-limited number has expired. The transaction is thus rejected at step 136. Otherwise, the transaction is authorized at step 150.” Note that at least two (2) rules must be met for met for the transaction to be approved --- the user device must be correctly identified and the time-limited number must be un-expired or still-valid.
Note that, while none of the references teaches all of these rules, it would be obvious to one of ordinary skill in the art to combine Mogollon and Sandstrom for a more secure temporary card.
Applicant argues, regarding claims 1, 9, and 15, as currently amended, that nothing in the cited references teaches, discloses, or suggests “storing, by the service provider system, an association between the plurality of validity rules and the temporary payment card information”.
Examiner respectfully disagrees.
Attention is directed to Mogollon at par 31-32 “DSC code may be associated with a specific transaction account, such that the DSCs may only be used in connection with the specific transaction account. However, in various embodiments, the code may be a customer level code, such that a DSC generated by the code may be used in connection with multiple transaction accounts associated with the consumer. DSCG may store a plurality of DSCs for a transaction account. The DSCs may be stored in a database, table, list, or any other storage area capable of storing one or more DSCs . . . transaction account issuer 140 may associate the requested DSC with the proper transaction account holder (e.g. generally user 102) (step 1115). Transaction account issuer system 140 may receive this request for a DSC. Transaction account issuer system 140 may identify the correct transaction account and/or transaction account holder (user 102) and issue/generate a DSC. Transaction account issuer system 140 may store the issued DSC in a lookup table for associating with a transaction authorization request”.
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 (i.e., changing from AIA to pre-AIA ) 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-4, 6-7, 9-11, 13-17, 19, and 22-27, are rejected under 35 U.S.C. 103 as being unpatentable over Mogollon et al (US 2013/0346314) in view of Scipioni et al (US 2009/0132417), Sandstrom et al (US 2010/0089998), and Hoffman et al (EP 1 117 035 A1).
Regarding claims 1, 9 and 15 –
Mogollon discloses receiving, at the service provider system and from the service provider hardware, a first request to perform a transaction with the merchant via a user account associated with the user device; (par 27-29 “User 102 may interact with a merchant point of sale, such as merchant 104 website/webpage. User 102 may select items for purchase from the merchant 104 website/webpage. At any point, once third party web browser application 150 is enabled, user 102 may log on to third party web browser application 150 to access secure preference information and/or to enable various personalized enhanced capabilities of third party web browser application 150 application” at par 27)
generating, by the service provider system, based at least in part on the first request and in near real-time, the temporary payment card information associated with the user account(see, par 50 with respect to temporary/proxy account information; also “At any point, once third party web browser application 150 is enabled, user 102 may log on to third party web browser application 150 to access secure preference information and/or to enable various personalized enhanced capabilities of third party web browser application (par 27) ... 102 may select a particular transaction account designator, such as a by accessing a virtual icon displayed by third party web browser application 150 (step 1105). This may prompt third party web browser application 150 to automatically populate various fields of the merchant checkout website with data associated with the selected transaction account (par 29) ...User 102 may input the DSC in the security code field on the merchant webpage (step 1145). According to various embodiments, the transaction account issuer system 140 message may automate this inputting...” (par 36, also par 26-29, 36)) the temporary payment card information:
representing a temporary payment card using a payment card number, an expiration date, and a verification value; (“The personalized web browsing application may be configured to perform electronic form filling. The method may include generating the dynamic security code, and determining the contact information of a holder of a transaction account associated with the request to generate a dynamic security code (par 14) ... to complete the transaction (e.g. to make a purchase) such as by using third party web browser application 150. (par 25) “When communicating with merchant 104 through a mobile device or a computer user 102 may provide information associated with a transaction instrument (e.g., transaction account number or code, expiration date, account name, and billing address) to merchant 104 to complete a transaction.” (par 26) “Third party web browser application 150 may determine the transaction account issuer 140 of the transaction account selected (step 1110)... (par 30) Third party web browser application 150 may transmit identification information, such as a user name, proxy user identifier, transaction account identifier, and/or the like (par 32) ...issuer 140, may issue a proxy account number to be populated by third party web browser application 150...” (par 50))
storing, by the service provider system, an association between the plurality of validity rules and the temporary payment card information; (par 31-32 “DSC code may be associated with a specific transaction account, such that the DSCs may only be used in connection with the specific transaction account. However, in various embodiments, the code may be a customer level code, such that a DSC generated by the code may be used in connection with multiple transaction accounts associated with the consumer. DSCG may store a plurality of DSCs for a transaction account. The DSCs may be stored in a database, table, list, or any other storage area capable of storing one or more DSCs . . . transaction account issuer 140 may associate the requested DSC with the proper transaction account holder (e.g. generally user 102) (step 1115). Transaction account issuer system 140 may receive this request for a DSC. Transaction account issuer system 140 may identify the correct transaction account and/or transaction account holder (user 102) and issue/generate a DSC. Transaction account issuer system 140 may store the issued DSC in a lookup table for associating with a transaction authorization request”)
sending, by the service provider system and responsive to the first request to perform the transaction with the merchant, the temporary payment card information to the user device; (par 14 “financial institution computer based system receiving a request to generate a dynamic security code from a personalized web browsing application. The personalized web browsing application may be configured to perform electronic form filling. The method may include generating the dynamic security code, and determining the contact information of a holder of a transaction account associated with the request to generate a dynamic security code” (where dynamic security code = temporary payment card information); also par 23, 26-30, “At any point, once third party web browser application 150 is enabled, user 102 may log on to third party web browser application 150 to access secure preference information and/or to enable various personalized enhanced capabilities of third party web browser application... 102 may select a particular transaction account designator, such as a by accessing a virtual icon displayed by third party web browser application 150 (step 1105). This may prompt third party web browser application 150 to automatically populate various fields of the merchant checkout website with data associated with the selected transaction account.”)
automatically populating, by the service provider, at least a portion of the temporary payment card information into a plurality of fields of the user interface; (par 23, 26-30, “At any point, once third party web browser application 150 is enabled, user 102 may log on to third party web browser application 150 to access secure preference information and/or to enable various personalized enhanced capabilities of third party web browser application... 102 may select a particular transaction account designator, such as a by accessing a virtual icon displayed by third party web browser application 150 (step 1105). This may prompt third party web browser application 150 to automatically populate various fields of the merchant checkout website with data associated with the selected transaction account.”)
receiving, from a merchant device associated with the merchant, a second request to approve the transaction, the second request comprising at least the portion of the temporary payment card information; (par 39 “the transaction account issuer 140 may transmit separate authorization responses to the merchant 104 and user 102.”)
Sandstrom discloses, as Mogollon does not, and in analogous art, indicating a plurality of validity rules that restrict a usability of the temporary payment card information, wherein the plurality of validity rules include a plurality of validity criteria to be satisfied prior to approval of the transaction, and wherein the plurality of validity criteria includes at least one of: a maximum transaction amount, a maximum number of transactions, a restriction that limits usability of the temporary payment card to the merchant, or an expiration time. (par 5 “validating the time-limited number for the transaction based on the digits indicating the expiration date . . . .”, par 58 “allocate 50,000 of the available numbers to be used as single-use payment card numbers . . . If the number has not been involved in a previous transaction, the financial institution authorizes the current transaction and removes the number from the list of useable numbers. Otherwise, the transaction is rejected . . .” where single use is a validity rule/criterion which is satisfied then the number has not been previously used, also par 31-33 “user device 12 (FIG. 1) transmits information capable of identifying the user, other than information corresponding to the user's payment card number, along with the time-limited number. The other information could be a device signature, such as a service-subscriber or international mobile subscriber identity (“IMSI”). . . . financial institution software normalizes the date on which the payment card transaction was effected to 00:00:00 GMT in a manner identical to that described above with respect to step 114. At step 144, the financial institution software calculates the number of days between the normalized transaction-effected date and the payment card's expiration date. At step 146, the software extracts the last five digits of the PAN of the alternate number and, at step 148, compares the extracted digits to the number of days determined at step 144. If the number of days calculated at step 144 is less than the extracted five digits, this indicates that the alternate, time-limited number has expired. The transaction is thus rejected at step 136. Otherwise, the transaction is authorized at step 150.” Note that at least two (2) rules must be met for met for the transaction to be approved --- the user device must be correctly identified and the time-limited number must be un-expired or still-valid.
However, Mogollon discloses at par 43 “IP addresses associated with the user computing device, number of password attempts, number of username attempts, correct password, time of day, country code associated with data transmission, and/or correct username”, par 47 “DSC is only valid with the particular transaction account for a limited period of time” (expiration time that is distinct from expiration date), par 79 “transaction account issuer 140 may determine that the time received of authorization request is not within a specified amount of the time received of request”.
Note that, while none of the references teaches all of these rules, it would be obvious to one of ordinary skill in the art to combine Mogollon and Sandstrom as well as increasing the number of rules or parameters, for a more secure temporary card.
Sandstrom further discloses retrieving, by the service provider system and using at least the portion of the temporary payment card information in the second request, the plurality of validity rules based on the association with the temporary payment card information par 5, 58, also par 31-33, as above)
verifying, by the service provider system, that the transaction satisfies the plurality of validity rules, including determining that the second request is received before the expiration time and that the transaction corresponds to the merchant in accordance with the restriction that limits the usability of the temporary payment card information to the merchant; (par 5, 58, also par 31-33, as above) and
approving the transaction based at least in part on the transaction satisfying the plurality of validity rules. (par 5, 58, also par 31-33, as above)
It would be obvious to one of ordinary skill in the art to combine Mogollon and Sandstrom for a more secure temporary card.
Mogollon does not specifically disclose publishing, by service provider hardware that operates in a user device, a user interface at the user device, wherein the user interface displays a control to obtain temporary payment card information via a service provider system associated with the service provider hardware, the service provider system being remote from a merchant and being configured to facilitate transactions involving user accounts of users of the service provider system.
However, Hoffman discloses, in analogous art, publishing, by service provider hardware that operates in a user device, a user interface at the user device (par 179, “ . . publish an interface in another environment. That means an interface is mapped from a source environment to a target environment so that methods may be invoked on a mapped interface in the target environment.”)
It would be obvious to one of ordinary skill in the art to combine Mogollon with the published interface of Hoffman for enhanced user ease.
Scipioni discloses, as Mogollon does not, wherein the user interface displays a control to obtain temporary payment card information via a service provider system associated with the service provider hardware, the service provider system being remote from a merchant and being configured to facilitate transactions involving user accounts of users of the service provider system. (Par 9, 11, abs)
It would be obvious to one of ordinary skill in the art to combine Mogollon and Hoffman, with the interface functions of Scipioni for greater user ease.
Mogollon does not specifically disclose publishing, by service provider hardware that operates in a user device, a user interface at the user device, wherein the user interface displays a control to obtain temporary payment card information via a service provider system associated with the service provider hardware, the service provider system being remote from a merchant and being configured to facilitate transactions involving user accounts of users of the service provider system.
However, Hoffman discloses, in analogous art, publishing, by service provider hardware that operates in a user device, a user interface at the user device (par 179, “ . . publish an interface in another environment. That means an interface is mapped from a source environment to a target environment so that methods may be invoked on a mapped interface in the target environment.”)
It would be obvious to one of ordinary skill in the art to combine Mogollon with the published interface of Hoffman for enhanced user ease.
However, Hoffman discloses, in analogous art, publishing, by service provider hardware that operates in a user device, a user interface at the user device (par 179, “ . . publish an interface in another environment. That means an interface is mapped from a source environment to a target environment so that methods may be invoked on a mapped interface in the target environment.”)
It would be obvious to one of ordinary skill in the art to combine Mogollon with the published interface of Hoffman for enhanced user ease.
Regarding claim 2 –
Sandstrom discloses wherein generating the temporary payment card information is based at least in part on receiving a previous interface-based input requesting use of the temporary payment card information. (par 18-20, 34-35)
It would be obvious to one of ordinary skill in the art to combine Mogollon and Sandstrom for better and more flexible temporary card.
Regarding claim 3 –
Sandstrom discloses that generating the temporary payment card information is based at least in part on determining that a payment instrument is unassociated with the user account as of a time of receipt of the first request. (par 18-20, 34-35)
It would be obvious to one of ordinary skill in the art to combine Mogollon and Sandstrom for better and a more flexible temporary card.
Regarding claim 4 –
Sandstrom discloses that generating the temporary payment card information is based at least in part on determining that a payment instrument associated with the service provider system is absent from the user account as of a time of receipt of the first request. (par 18-20, 34-35)
It would be obvious to one of ordinary skill in the art to combine Mogollon and Sandstrom for a more flexible temporary card.
Regarding claim 6 –
Sandstrom discloses receiving, from the merchant device, an indication that the temporary payment card information has been utilized to satisfy a cost of the transaction; (par 58)
identifying the user account associated with the temporary payment card information; (par 58) and
initiating withdrawal of funds equal to the cost from the user account. (par 58)
receiving, from the merchant device, an indication that the temporary payment card information has been utilized to satisfy a cost of the transaction; (par 58)
identifying the user account associated with the temporary payment card information; and initiating withdrawal of funds equal to the cost from the user account. (par 58)
It would be obvious to one of ordinary skill in the art to combine Mogollon and Sandstrom for a more flexible temporary card.
Regarding claim 7 –
Sandstrom discloses wherein the plurality of validity rules includes a validity rule that indicates that the temporary payment card information is valid for exactly one transaction, and further comprising:
determining that the temporary payment card information remains unused, (par 58) wherein sending the temporary payment card information is based at least in part on the temporary payment card information used remaining unused. (par 58)
It would be obvious to one of ordinary skill in the art to combine Mogollon and Sandstrom for a more flexible temporary card for greater ease by the user.
Regarding claim 10 –
Mogollon teaches wherein, prior to sending the temporary payment card information to the user device, the operations further comprise: presenting a merchant interface in association with a payment application through the user device, wherein the merchant interface is associated with the merchant. (par 46).
Regarding claim 11 –
Mogollon teaches wherein the merchant interface is associated with a merchant ecommerce website, (par 46) and wherein sending the temporary payment card information includes sending the temporary payment card information to the merchant ecommerce website. (par 46)
Regarding claim 13 -
Sandstrom teaches wherein generating the temporary payment card information is based at least in part on receiving the input data. (par 18-20, 34-35)
Scipioni discloses causing display, on the merchant interface, of a selectable element; (par 11, 47,52)
receiving user input data indicating selection of the selectable element. (par 11, 47,52)
It would be obvious to one of ordinary skill in the art to combine Mogollon and Sandstrom with the elements of Scipioni for enhanced user ease.
Regarding claim 14 -
Mogollon teaches the operations further comprising:
in response to receiving the first request, requesting authentication input from a user associated with a user account; (par 49, 63) and
receiving the authentication input; (par 49, 63)
wherein sending the temporary payment card information is based at least in part on receiving the authentication input. (par 49, 63)
Regarding claim 16 –
Mogollon teaches that the merchant interface is associated with a merchant ecommerce website; (par 46) and wherein sending the temporary payment card information includes sending the temporary payment card information to the merchant ecommerce website. (par 46)
Regarding claim 17 –
Sandstrom discloses wherein herein the plurality of validity rules includes a validity rule that indicates that the temporary payment card information is valid for exactly one transaction (par 58), and further comprising:
determining that the temporary payment card information remains unused, wherein sending the temporary payment card information is based at least in part on the temporary payment card information remaining unused. (par 58)
It would be obvious to one of ordinary skill in the art to combine Mogollon and Sandstrom for a more flexible temporary card for greater ease by the user.
Regarding claim 19 –
Sandstrom discloses wherein generating the temporary payment card information is based at least in part on determining that a payment instrument associated with the service provider system is absent from the user account as of a time of receipt of the first request. (par 18-20, 34-35)
It would be obvious to one of ordinary skill in the art to combine Mogollon and Sandstrom for a more flexible temporary card for greater ease by the user.
Regarding claim 22 –
Sandstrom discloses wherein the temporary payment card information corresponds to a physical payment card that is associated with the user account. (par 20)
It would be obvious to one of ordinary skill in the art to combine Mogollon and Sandstrom for a more secure temporary card.
Regarding claim 23 –
Sandstrom discloses determining that a number of transactions for which the temporary payment card is less than the maximum number of transactions. (par 58)
Scipioni discloses determining that a transaction amount associated with the temporary payment card is less than the maximum transaction amount. (par 63)
It would be obvious to one of ordinary skill in the art to combine Mogollon and Sandstrom with the elements of Scipioni for enhanced user ease.
Regarding claim 24 –
Scipioni discloses a maximum transaction amount (par 63)
Sandstrom discloses a maximum number of transactions (par 58)
While the references do not specifically disclose wherein both apply to one of an individual or a group, they do disclose multiple rules applied simultaneously and it would be obvious to one of ordinary skill the art to combine these rules for a more secure transaction.
Further, the difference between one validity rule or another are only found in the non-functional descriptive material and are not functionally involved in the steps recited. In other words, it has to do with whether one rule or another is being met, not what the rule is. The various steps would be performed the same regardless of the descriptive material since none of the steps explicitly interact therewith. Limitations that are not functionally interrelated with the useful acts, structure, or properties of the claimed invention carry little or no patentable weight. Thus, this descriptive material will not distinguish the claimed invention from the prior art in terms of patentability, see In re Ngai, 70 USPQ2d 1862 (CAFC 2004); In re Gulack, 703 F.2d 1381, 1385, 217 USPQ 401, 404 (Fed. Cir. 1983); In re Lowry, 32 F.3d 1579, 32 USPQ2d 1031 (Fed. Cir. 1994).
Therefore, it would also have been obvious to a person of ordinary skill in the art at the time of applicant’s invention to include one rule or another because such data does not functionally relate to the steps in the method claimed and because the subjective interpretation of the data does not patentably distinguish the claimed invention.
Regarding claims 27 –
Sandstrom discloses wherein the plurality of validity rules includes the expiration date. (par 5 “validating the time-limited number for the transaction based on the digits indicating the expiration date . . . .”,)
It would be obvious to one of ordinary skill in the art to combine Sandstrom with Mogollon in order to obtain a more secure transaction.
Further, the difference between one validity rule or another are only found in the non-functional descriptive material and are not functionally involved in the steps recited. In other words, it has to do with whether one rule or another is being met, not what the rule is. The various steps would be performed the same regardless of the descriptive material since none of the steps explicitly interact therewith. Limitations that are not functionally interrelated with the useful acts, structure, or properties of the claimed invention carry little or no patentable weight. Thus, this descriptive material will not distinguish the claimed invention from the prior art in terms of patentability, see In re Ngai, 70 USPQ2d 1862 (CAFC 2004); In re Gulack, 703 F.2d 1381, 1385, 217 USPQ 401, 404 (Fed. Cir. 1983); In re Lowry, 32 F.3d 1579, 32 USPQ2d 1031 (Fed. Cir. 1994).
Therefore, it would also have been obvious to a person of ordinary skill in the art at the time of applicant’s invention to include one rule or another because such data does not functionally relate to the steps in the method claimed and because the subjective interpretation of the data does not patentably distinguish the claimed invention.
Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Mogollon et al (US 2013/0346314) in view of Scipioni et al (US 2009/0132417), Hoffman et al (EP 1 117 035 A1), and Sandstrom et al (US 2010/0089998) and further in view of Mukherjee (US 2012/0259768).
Mogollon, in view of Sandstrom, Hoffman, and Scipioni, teaches as above.
Regarding claim 8 –
Mukherjee discloses that generating the temporary payment card information is based at least in part on an indication that the merchant corresponds to a predetermined merchant and the transaction is set to occur at a predetermined time. (par 24, 49)
It would be obvious for one of ordinary skill in the art to combine Mogollon, Sandstrom, Hoffman, and Scipioni, with Mukherjee for better control over finances.
Regarding claim 18 -
Mukherjee teaches wherein generating the temporary payment card information is based at least in part on an indication that the merchant corresponds to a predetermined merchant and the transaction is set to occur at a predetermined time. (par 24, 49)
It would be obvious for one of ordinary skill in the art to combine Mogollon, Sandstrom, Hoffman, and Scipioni, with Mukherjee for better control over finances.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CRISTINA OWEN SHERR whose telephone number is (571)272-6711. The examiner can normally be reached 8:30 - 5:30.
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, John W Hayes can be reached at 571-272-6708. 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.
/Cristina Owen Sherr/ Examiner, Art Unit 3697
/JOHN W HAYES/ Supervisory Patent Examiner, Art Unit 3697
Prosecution Insights