DETAILED ACTION
Acknowledgements
This office action is in response to the claims filed 04/10/2024.
Claims 5, 7, 10, 13, 14, 17 and 18 are amended.
Claim 15 is cancelled.
Claims 19-21 are new.
Claims 1-14, and 16-21 are pending.
Claims 1-14, and 16-21 have been examined.
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 .
Claim Objections
Claims 7 and 17 are objected to because of the following informalities: claim 7 recites “pushes the payment token to to a merchant server”, claim 17 recites “the one or more processors implement following actions, claim 18 recites “implements following actions”. Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-14, and 16-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Subject Matter Eligibility Standard
When considering subject matter eligibility under 35 U.S.C. § 101, it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter (101 Analysis: Step 1). Even if the claim does fall within one of the statutory categories, it must then be determined whether the claim is directed to a judicial exception (i.e., law of nature, natural phenomenon, and abstract idea) (101 Analysis: Step 2a(Prong 1), and if so, Identify whether there are any additional elements recited in the claim beyond the judicial exception(s), and evaluate those additional elements to determine whether they integrate the exception into a practical application of the exception. (101 Analysis: Step 2a (Prong 2). If additional elements does not integrate the exception into a practical application of the exception, claim still requires an evaluation of whether the claim recites additional elements that amount to an inventive concept (aka “significantly more”) than the recited judicial exception. If the claim as a whole amounts to significantly more than the exception itself (there is an inventive concept in the claim), the claim is eligible. If the claim as a whole does not amount to significantly more (there is no inventive concept in the claim), the claim is ineligible. (101 Analysis: Step 2b).
The 2019 PEG explains that the abstract idea exception includes the following groupings of subject matter: a) Mathematical concepts b) Certain methods of organizing human activity and c) Mental processes
Analysis
In the instant case, claim 1 is directed to a method, and claims 16-18 are directed to an article of manufacture.
Step 2a.1– Identifying an Abstract Idea
The claims recite the steps of “parsing a payment token acquisition request … sending the wallet payment password … sending a sub-wallet opening request …receiving a sub-wallet opening result … and sending a payment token generation request ….” The recited limitations fall within the certain methods of organizing human activity grouping of abstract ideas, specifically, fundamental economic principles, for example, sending requests for information for a third party to open an account. Accordingly, the claims recites an abstract idea.
See MPEP 2106.
Step 2a.2 – Identifying a Practical Application
The claim does not currently recite any additional elements or combination of additional elements that integrate the judicial exception into a practical application.
Apart from looking at the contents of a request for information, “parsing a payment token acquisition request…”, the remaining limitations recite the sending and receiving of information, which are insignificant extra-solution activity of a generic computing device.
Accordingly, even in combination, these elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Mere instructions to apply the exception using generic computer components and limitations to a particular field of use or technological environment do not amount to practical applications. The claim in directed to an abstract idea.
Step 2b
The claim limitations recite “parsing a payment token acquisition request … sending the wallet payment password … sending a sub-wallet opening request …receiving a sub-wallet opening result … and sending a payment token generation request ….” are not additional elements and they amount to no more than mere instructions to apply the exception using a generic computer component. For the same reason these elements are not sufficient to provide an inventive concept. This is also determined to be well-understood, routine and conventional activity in the field. The Symantec, TLI, and OIP Techs, court decision cited in MPEP 2106.05(d)(II) indicates that mere receipt or transmission of data over a network is a well-understood, routine and conventional function when it is claimed in a merely generic manner, as it is here. Therefore, when considering the additional elements alone, and in combination, there is no inventive concept in the claim and thus the claim is not eligible.
Viewed as a whole, instructions/method claims recite the concept of a fundamental economic practice as performed by a generic computer. The claims do not currently recite any additional elements or combination of additional elements that amount to significantly more than the judicial exception. The elements used to perform the claimed judicial exception amount to no more than mere instructions to implement the abstract idea in a network, and/or merely uses a network as a tool to perform an abstract idea and/or generally linking the use of the judicial exception to a particular environment.
Dependent claims 2-4, 7, 8, 10-14 and 19-21 discuss functions in more descriptive detail of the steps geared toward the abstract idea. As such, these elements do not provide the significantly more to the underlying abstract idea necessary to render the invention patentable.
Claims 5, 6, and 9 provide descriptive language surrounding the abstract idea. As such, these elements do not provide the significantly more to the underlying abstract idea necessary to render the invention patentable.
The claims do not, for example, purport to improve the functioning of the computer itself. Nor do they effect an improvement in any other technology or technical field. Therefore, based on case law precedent, the claims are claiming subject matter similar to concepts already identified by the courts as dealing with abstract ideas. See Alice Corp. Pty. Ltd., 573 U.S. 208 (citing Bilski v. Kappos, 561, U.S. 593, 611 (2010)).
The claims at issue amount to nothing significantly more than an instruction to apply the abstract idea using some unspecified, generic computer. See Alice Corp. Pty. Ltd., 573 U.S. 208. Mere instructions to apply the exception using a generic computer component and limitations to a particular field of use or technological environment cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Therefore, the claim is not patent eligible.
Conclusion
The claim as a whole, does not amount to significantly more than the abstract idea itself. This is because the claim does not affect an improvement to another technology or technical filed; the claim does not amount to an improvement to the functioning of a computer system itself; and the claim does not move beyond a general link of the use of an abstract idea to a particular technological environment.
Accordingly, the Examiner concludes that there are no meaningful limitations in the claim that transform the judicial exception into a patent eligible application such that the claim amounts to significantly more than the judicial exception itself.
Dependent claims do not resolve the deficiency of independent claims and accordingly stand rejected under 35 USC 101 based on the same rationale.
Dependent claims 2-14 and 19-21are also rejected.
Claim 18 recites “A nonvolatile computer-readable medium, on which a computer program is stored, wherein the program, when being executed by a processor, implements following actions:”. Under broadest reasonable interpretation of the claim, a “nonvolatile computer-readable medium” can include non-transitory and transitory storage mediums. Therefore, the claimed “nonvolatile computer-readable medium” can be directed to a signal per se. A signal is a carrier wave or other propagation media, according to MPEP 2106 II IV, however, there are four categories of invention: process, machine, article of manufacture or composition of matter, therefore, as a "signal" is not a category of invention nor a subset of one of the categories, it does not represent patent eligible subject matter. See In re Nuijten, 84 U.S.P.Q.2d 1495 (Fed. Cir. 2007), Gottschalk v. Benson, 409 U.S. at 72, 175 USPQ at 676-77.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 5, 10 and 12 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claim 5, recites “judging whether there is the account information of the target merchant in a local storage device of the terminal; if so, acquiring the account information”. The claim is unclear and indefinite. The claim is unclear as to what computer function “judging” is and what process or capabilities a computer would be performing or have in order to “judge”. The claims are unclear and indefinite.
Claim 10 recites “after generating the digital currency sub-wallet corresponding to the target digital wallet and the target merchant, in response to a limit query request of the user for a sub-wallet to be queried, acquiring a sub-wallet limit”, similarly, claim 12 recites “after generating the digital currency sub-wallet corresponding” and claim 1 recites “sending a sub-wallet opening request to the operating system of the target digital wallet, so that the operating system of the target digital wallet generates a digital currency sub-wallet….” The claims are unclear and indefinite. The scope of claim 1 does not claim the functions of the operating system that generates the sub-wallet. A message is sent for generating the sub-wallet, but claim 1 does not positively recite generating the sub-wallet. Claims 10 and 12 are therefore outside the scope of claim 1, as it now recites the functions of the operating system that generated the sub-wallet. The claim is unclear and indefinite.
Claim Rejections - 35 USC § 103
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-14, and 16-21 are rejected under 35 U.S.C. 103 as being unpatentable over Kalaboukis et al. (US 10929841) (“Kalaboukis”), and further in view of Pomeroy et al. (US 20160086166) (“Pomeroy”).
Regarding claims 1, and 16-18, Kalaboukis discloses parsing a payment token acquisition request of a user, as to obtain a target digital wallet, a target merchant, and a wallet payment password corresponding to the target digital wallet (column 19, line 14-67, column 20, line 1-67);
Claim Interpretations- According to the disclosure (¶ 181-185),Figure 4 and 5, “As shown in FIG. 5 , the payment tokenization system 500 based on the digital currency sub-wallet includes a digital wallet system 501, a token service provider 502 and an operating system 503, wherein,”
Kalaboukis - At process 302, a mobile wallet account for a user is registered. In some arrangements, the mobile wallet computing system 104 receives a request for a mobile wallet account from the user mobile device 102. For example, the user may access a website associated with the mobile wallet provider via the user mobile device 102 and indicate a preference to register for the mobile wallet… The registration interfaces may request various forms of information from the user. For example, a registration interface may prompt the user to establish login credentials for the mobile wallet, or input information that can be used to authenticate the user… The mobile wallet system 138 may also communicate with the identity verification circuit 160 discussed above to verify the new mobile wallet user's identity. For instance, the mobile wallet system 138 may transmit scanned images of a user's driver's license to the identity verification circuit 160 for further processing and authentication… An another example, the user may register a pass, ticket, or reservation, such as a movie ticket, a concert ticket, a boarding pass, a train ticket, a hotel reservation, and the like by taking a picture of the pass, ticket, or reservation using a camera of the user mobile device 102, with the mobile wallet application 126 transmitting the picture to the mobile wallet system 138. (column 19, line 14-67, column 20, line 1-67)
sending the wallet payment password to an operating system of the target digital wallet, so that the operating system of the target digital wallet verifies the wallet payment password, and receiving a verification result returned by the operating system of the target digital wallet (column 19, line 14-67, column 20, line 1-67, column 21, line 1-67, column 23, line 1-67, column 24, line 1-67);
Kalaboukis - The registration interfaces may request various forms of information from the user. For example, a registration interface may prompt the user to establish login credentials for the mobile wallet, or input information that can be used to authenticate the user… The mobile wallet system 138 may also communicate with the identity verification circuit 160 discussed above to verify the new mobile wallet user's identity. For instance, the mobile wallet system 138 may transmit scanned images of a user's driver's license to the identity verification circuit 160 for further processing and authentication… Once the user has registered one or more digital items to the master wallet, the user may create one or more sub-wallets that include the registered digital items… For example, the user may register a wholesale club card, a credit card associated with the wholesale club, a driver's license, coupons, and a business credit card to the master wallet. Based on these digital items, the mobile wallet system 138 may recommend that the user create a wholesale club sub-wallet including the wholesale club card, the credit card associated with the wholesale club, and the coupons (column 19, line 14-67, column 20, line 1-67).
in a case that the verification result is passed, sending a sub-wallet opening request to the operating system of the target digital wallet, (column 15, line 1-18, column 20, line 52-67)
Kalaboukis - For example, if the user has provisioned a travel rewards card, a credit card with no foreign transaction fees, and boarding passes to the master wallet, the sub-wallet registration circuit 206 may suggest that the user create a travel sub-wallet with these items included therein….(column 15, line 1-18)
and receiving a sub-wallet opening result returned by the operating system of the target digital wallet; and (column 20, line 52-67, column 21, line 1-25)
Kalaboukis - At process 308, one or more rules are configured for each sub-wallet that determine when the mobile wallet computing system 104 should provision the predefined sub-wallet to the mobile wallet on the user mobile device 102. (column 20, line 52-67, column 21, line 1-25)
in a case that wallet opening is successful, sending a payment token generation request to a token service provider, so that the token service provider generates a payment token corresponding to the digital currency sub-wallet, and receiving a payment token generation result returned by the token service provider (column 5, line 22-64, column 13, line 1-46, column 17, line 28-67, column 21, line 26-45).
Claim Interpretation – The claim recites “…so that…”, the language is a result and therefore has not patentable weight ( Minton v. Nat’l Ass’n of Securities Dealers, Inc., 336 F.3d 1373, 1381, 67 USPQ2d 1614, 1620 (Fed. Cir. 2003)) that a “‘whereby clause in a method claim is not given weight when it simply expresses the intended result of a process step positively recited.’” See MPEP 2111.04.
Kalaboukis - For example, the mobile wallet computing system 104 may request from the token service provider computing system 108 tokens for items registered by the user and stored to the mobile wallet database 140. … In response to a token request for a sub-wallet from the mobile wallet computing system 104, the sub-wallet token generator 180 may create a token (e.g., a random number, a random set of alphanumeric characters, the output of a tokenization algorithm) for the sub-wallet….As another example, the token service provider computing system 108 may generate and assign a random number or string of alphanumeric characters to each of the user's sub-wallets. The random numbers or strings of alphanumeric characters are then stored in the mobile wallet computing system 104 and/or the token service provider computing system 108 as tokens for the sub-wallets. Subsequently, once the rules or conditions associated with a given sub-wallet are fulfilled, the mobile wallet computing system 104 automatically populates a mobile wallet on the user mobile device 102 with the tokenized items in the given sub-wallet and/or with the token representing the given sub-wallet… n The token generator 178 may then store each token, as well as the token's association with the corresponding item, in the token database 182. Alternatively, or additionally, the token generator 178 may provide the token to the mobile wallet computing system 104, which may store the token in a token vault maintained internally within the mobile wallet computing system 104 (e.g., within the mobile wallet database 140). (column 5, line 22-64, column 13, line 1-46, column 17, line 28-67, column 21, line 26-45)
Kalaboukis does not disclose so that the operating system of the target digital wallet generates a digital currency sub-wallet corresponding to the target digital wallet and the target merchant.
Pomeroy teaches so that the operating system of the target digital wallet generates a digital currency sub-wallet corresponding to the target digital wallet and the target merchant, (¶ 83-90, 133-141)
Pomeroy - Using information contained within the electronic wallet transaction received from the point of sale device 111 and/or from information obtained from datastore 180, in block 304, the electronic value token transaction computer 150 determines whether the request is an electronic wallet request containing valid authentication information and whether the request is for redemption of a value token(s),… If the request is for electronic value token addition, then in block 306, the electronic sub-wallet is created (if not already created) and the electronic value token is added to the electronic sub-wallet. (¶ 83, 141)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Kalaboukis and Pomeroy in order to eliminate complexities of security and management of payment instruments with the use of tokens in wallets (Pomeroy; ¶ 37).
Regarding claim 2, Pomeroy teaches before receiving the payment token acquisition request of the user, acquiring a merchant list of the user from the token service provider, and sending the merchant list to a terminal for display, so that the user selects one or more merchants from the merchant list as the target merchant; or, before receiving the payment token acquisition request of the user, acquiring a digital wallet list of the user, and sending the digital wallet list to a terminal for display, so that the user selects the target digital wallet from the digital wallet list (Fig 6D; ¶ 34, 39, 47, 56, 57, 71, 89, 108, 167, 258).
Claim Interpretation – The claim recites “…merchant; or, before receiving…”, this is optional language, and therefore does not have patentable weight. See MPEP 2103(I)(c).
Regarding claim 3, Pomeroy teaches after acquiring the digital wallet list of the user and sending the digital wallet list to the terminal for display, in response to an operation of the user for selecting the target digital wallet from the digital wallet list, acquiring a merchant list corresponding to the target digital wallet, and sending the merchant list to the terminal for display, so that the user selects, from the merchant list corresponding to the target digital wallet, one or more merchants as the target merchant (Fig 3B, 6C, D; ¶ 34, 39, 47, 56, 57, 71, 89, 108, 167, 171, 258).
Regarding claim 4, Pomeroy teaches after the user selects one or more merchants from the merchant list as the target merchant, acquiring account information of the target merchant, verifying the account information of the target merchant, and confirming that the verification is passed (¶ 63, 101, 102, 297, 306-309, 316, 317).
Regarding claim 5, Pomeroy teaches wherein acquiring the account information of the target merchant comprises: judging whether there is the account information of the target merchant in a local storage device of the terminal; if so, acquiring the account information of the target merchant from the local storage device; and otherwise, acquiring the account information of the target merchant from a merchant mechanism system of the target merchant, and storing the acquired account information of the target merchant in the local storage device (¶ 39, 48, 125-127, 136, 141, 182, 271, 272, 292).
Regarding claim 6, Pomeroy teaches wherein verifying the account information of the target merchant comprises: verifying whether real name information of the target merchant is consistent with communication information of the target merchant; if so, the verification is passed; and otherwise, the verification is not passed (¶ 39, 48, 76, 89, 125-127, 136, 141, 182, 271, 272, 292)
Regarding claim 7, Pomeroy teaches sending a request for pushing a payment token to the token service provider, so that the token service provider generates the payment token corresponding to the digital currency sub-wallet, and pushes the payment token to to a merchant server system of the target merchant via the operating system of the target digital wallet, the merchant mechanism system of the target merchant;
after the merchant server system of the target merchant receiving the payment token, acquiring a response message from the merchant server system of the target merchant via the merchant mechanism system of the target merchant, the operating system of the target digital wallet and the token service provider; and
wherein the merchant server system of the target merchant pushes the payment token to a merchant terminal of the target merchant, so that the merchant terminal of the target merchant displays the message pushed by the merchant server system of the target merchant (¶ 68, 69, 76-81, 89).
Regarding claim 8, Pomeroy teaches before sending the sub-wallet opening request to the operating system of the target digital wallet, confirming that there is no digital currency sub-wallet corresponding to the target digital wallet and the target merchant (¶ 83-90, 141, 169, 294, 307).
Regarding claim 9, Kalaboukis discloses wherein the payment token acquisition request comprises: a plurality of consumption accounts of the user in the target merchant; and sending the payment token generation request to the token service provider comprises: respectively sending, to the token service provider, a payment token generation request corresponding to each consumption account, so that the token service provider respectively generates a payment token corresponding to each consumption account (column 5, line 22-64, column 13, line 1-46, column 17, line 28-67, column 21, line 26-45).
Regarding claim 10, Kalaboukis discloses after generating the digital currency sub-wallet corresponding to the target digital wallet and the target merchant, in response to a limit query request of the user for a sub-wallet to be queried, acquiring a sub-wallet limit of the sub-wallet to be queried, and sending the sub-wallet limit to a terminal for display; or, after generating the digital currency sub-wallet corresponding to the target digital wallet and the target merchant, receiving a limit modification request of the user, parsing the limit modification request, as to obtain a sub-wallet to be adjusted of which a limit is to be adjusted, and a target limit thereof, and sending the sub-wallet to be adjusted and the target limit thereof to an operating system corresponding to the sub-wallet to be adjusted, so that the operating system corresponding to the sub-wallet to be adjusted adjusts a sub-wallet limit of the sub-wallet to be adjusted to the target limit (column 5, line 22-64, column 13, line 1-46, column 17, line 28-67, column 21, line 26-45).
Regarding claim 11, Pomeroy teaches before receiving the limit modification request of the user, acquiring a current limit of the sub-wallet to be adjusted, generating a sub-wallet limit management page according to the current limit of the sub-wallet to be adjusted, and sending the sub-wallet limit management page to the terminal for display, so that the user sets the target limit of the sub-wallet to be adjusted by means of an operation on the sub-wallet limit management page (¶ 56-59, 70, 76-79, 102, 125, 281).
Regarding claim 12, Pomeroy teaches after generating the digital currency sub-wallet corresponding to the target digital wallet and the target merchant, in response to a payment request of the user based on a target sub-wallet, verifying the payment request to determine that an amount to be paid is less than or equal to a sub-wallet limit of the target sub-wallet (¶ 56-59, 70, 76-79, 102, 125, 281).
Regarding claim 13, Pomeroy teaches after receiving the payment token generation result returned by the token service provider, acquiring a risk control level of the target digital wallet and historical consumption data of the consumption account of the user in the target merchant; and determining, according to the historical consumption data of the consumption account and the risk control level, a payment limit of the payment token corresponding to the consumption account (¶ 42, 56-59, 67-70, 76-79, 83, 107, 116-118, 134, 158, 176-176, 208, 236, 251).
Regarding claim 14, Pomeroy teaches receiving a collection request sent by a target merchant background system in response to a consumption request of a user, wherein the collection request comprises a payment token and a collection amount of the user, wherein a digital currency sub-wallet of the payment token corresponds to a target merchant; determining, according to the payment token, a target operation mechanism background system corresponding to the digital currency sub-wallet, and sending a collection request message to the target operation mechanism background system; and receiving digital currency transferred from the target operation mechanism background system in response to the collection request message, and when it is verified that the transferred digital currency is consistent with the collection amount, pushing payment result information to the target merchant background system, so that the target merchant background system pushes payment success information to the user (¶ 42, 56-59, 67-70, 76-79, 83, 107, 116-118, 134, 158, 176-176, 208, 236, 251).
Regarding claims 19- 21, Pomeroy teaches after generating the digital currency sub-wallet corresponding to the target digital wallet and the target merchant, in response to a limit query request of the user for a sub-wallet to be queried, acquiring a sub-wallet limit of the sub-wallet to be queried, and sending the sub-wallet limit to a terminal for display; or, after generating the digital currency sub-wallet corresponding to the target digital wallet and the target merchant, receiving a limit modification request of the user, parsing the limit modification request, as to obtain a sub-wallet to be adjusted of which a limit is to be adjusted, and a target limit thereof, and sending the sub-wallet to be adjusted and the target limit thereof to an operating system corresponding to the sub-wallet to be adjusted, so that the operating system corresponding to the sub-wallet to be adjusted adjusts a sub-wallet limit of the sub-wallet to be adjusted to the target limit (¶ 56-59, 70, 76-79, 102, 125, 281).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Osterkamp et al., (US 12333533) teaches creating temporary digital wallets.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ILSE I IMMANUEL whose telephone number is (469)295-9094. The examiner can normally be reached Monday-Friday 9:00 am to 5:00pm.
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, NEHA H PATEL can be reached on (571) 270-1492. 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.
/ILSE I IMMANUEL/Primary Examiner, Art Unit 3699