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 .
Status of the Application
This first action non-final rejection is in response to the claim set filed on 4/09/2025. Claims 1-20 are currently pending and have been examined below.
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. 12307477. Although the claims at issue are not identical, they are not patentably distinct from each other because independent patent claims 1, 8, and 15 of US. Patent No. 11386452 recite limitations of similar scope to all of the limitations in independent claims 1, 7, and 13 of the present claims, in addition to reciting additional imitations that further limit the patented claims. Therefore claims 1-20 of U.S. Patent No. 12307477 are in essence “species” of the generic invention of claims 1-20of the present application. It has been held that a generic invention is "anticipated" by a "species" within the scope of the generic invention. See In re Goodman, 29 USPQ2d 2010 (Fed. Cir. 1993).
Claim Rejections – 35 U.S.C. 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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Per step 1 of the eligibility analysis set forth in MPEP § 2106, subsection III, the claims are directed towards a process, machine, or manufacture.
Per step 2A Prong One, Claim 7 recites specific limitations which fall within at least one of the groupings of abstract ideas enumerated in MPEP 2106.04(a)(2) as follows:
identifying an eligible condition of a payment action for an owed balance has been met, the owed balance being associated with a user identifier at an entity;
displaying a payment action notification;
identify a selection of the payment action notification;
receiving a payment action; and
transmitting the payment action.
As noted above, these limitations fall within at least one of the groupings of abstract ideas enumerated in the MPEP 2106.04(a)(2). Specifically, these limitations fall within the group Certain Methods of Organizing Human Activity (i.e., fundamental economic principles or practices (including hedging, insurance, mitigating risk); commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations); managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions). That is – the limitations recite a method for notifying a customer of eligibility to make a payment on an owed balance and facilitation payment which is a commercial activity that falls within the certain method or organizing human activities grouping of abstract ideas.
Per step 2A Prong 2, the Examiner finds that the judicial exception is not integrated into a practical application. Claim 7 recites the additional limitations of:
[displaying a payment action notification] on a display of a client device;
activating a deep link for an application executed in the client device based at least in part on the selection of the payment action notification;
displaying a payment interface based at least in part on the activation of the deep link, the payment interface populating an identifier for a source account associated with the user identifier at the entity;
[receiving a payment action from] the payment interface; and
[transmitting the payment action to] a remote computing device.
The additional limitations when viewed individually and when viewed as an ordered combination, and pursuant to the broadest reasonable interpretation, do not integrate the abstract idea into a practical application because each of the additional elements are recited at high level of generality implementing the abstract idea on a computer (i.e. apply it) or generally linking the use of the judicial exception to a particular technological environment.
Specifically, the user of a generic client device with a generic payment interface to display a notification, receive a payment action, and transmit the action merely generally link the abstract idea to a particular technological environment or merely utilizes the a generic client device with a generic intefface as at a tool to perform the abstract idea.
With respect to activating a deep link for an application executed in the client device based at least in part on the selection of the payment action notification and displaying a payment interface based at least in part on the activation of the deep link, the payment interface populating an identifier for a source account associated with the user identifier at the entity, Examiner notes that these limitations are cited at a high level of generality and claimed functionality without providing any technological details as interface is populated. Specifically, paragraph [0018] of Applicant’s published specification recites that “[a] deep link can be a type of hyperlink that directs a client device to a specific client application location (e.g., a specific user interface of the client application)” but does not recite an improvement to underlying hyperlink technology. Claim limitations that attempt to cover any solution to an identified problem with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, does not integrate a judicial exception into a practical application or provide significantly more because this type of recitation is equivalent to the words “apply it”. Here, auto-populating the interface using a deep link provides only a results-oriented solution which does not integrate the abstract idea into a practical application.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements when considered both individually and as an ordered combination do not amount to significantly more than the abstract idea. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements are recited at a high level of generality and only generally link the use of the judicial exception to a particular technological environment. The same analysis applies here in 2B, i.e., mere instructions to apply an exception in a particular technological environment and insignificant extra-solution activity cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B.
Alice Corp. also establishes that the same analysis should be used for all categories of claims (e.g., product and process claims). Therefore, independent system claim 1 and non-transitory computer readable storage medium claim 13 are also rejected as ineligible subject matter under 35 U.S.C. 101 for substantially the same reasons as independent method claim 7. Specifically, processor and memory of system claim 1 and the non-transitory computer readable storage medium and processor of claim 13 add nothing of substance to the underlying abstract idea. At best, the components in independent claims 1 and 13 merely provide an environment to implement the abstract idea.
Dependent claims 2-6, 8-12, and 14-20 merely further narrow the abstract idea and/or generally link the abstract idea to a particular technological environment / apply it and therefore do not integrate the abstract idea into a practical application or amount to significantly more than the abstract idea.
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 of this title, 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-4, 7-10, 13-16, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent Application Publication 20190050845 (“Deshmukh”) in view of US Patent Application Publication Number 20210295403 (“Chan”).
Claims 1, 7, and 13
As per claims 1, 7, and 13 Deshmukh teaches a system, a method, and a non-transitory, computer-readable medium, comprising machine-readable instructions that, when executed by a processor of a client device, cause the client device to at least:
a client device comprising a processor and a memory ([0031] “system comprises a hardware processor; a memory adapted to store processor-executable instructions.” And, [0034] “computer readable instructions stored thereupon is disclosed, said computer readable instructions, when executed by a processor.”);
machine-readable instructions stored in the memory that, when executed by the processor, cause the client device to at least ([0031] “system comprises a hardware processor; a memory adapted to store processor-executable instructions.” And, [0034] “computer readable instructions stored thereupon is disclosed, said computer readable instructions, when executed by a processor.”):
identify an eligible condition of a payment action for an owed balance has been met, the owed balance being associated with a user identifier at an entity ([0031] “enables a user to pay bills directly from bill payment notifications . . . check and compare each message in the SMS inbox with a set of templates in order to identify the incoming SMS as bill payment message, the SMS identification module upon identification of the incoming message as bill payment notification, provides ‘pay now’ and ‘remind later’ icon . . . initiate payment of the bill when the user select option of pay now.” And, [0018] “extracts the payment information from the bill payment SMS received. The payment information comprises vendor details, bill amount.” See account number and owed balance displayed in the notification in Figure 4.);
display a payment action notification on a display of the client device ([0031] “enables a user to pay bills directly from bill payment notifications . . . check and compare each message in the SMS inbox with a set of templates in order to identify the incoming SMS as bill payment message, the SMS identification module upon identification of the incoming message as bill payment notification.” And, [0017] “SMS received on a mobile communication device.”);
identify a selection of the payment action notification ([0031] “initiate payment of the bill when the user select option of pay now on the SMS screen, which further displays a payment page through the bill payment application on the mobile communication device wherein the details on the payment page is automatically filled from the payment details extracted by the SMS identification module from the bill payment notification SMS.”);
activate an application executed in the client device based at least in part on the selection of the payment action notification ([0031] “initiate payment of the bill when the user select option of pay now on the SMS screen, which further displays a payment page through the bill payment application on the mobile communication device wherein the details on the payment page is automatically filled from the payment details extracted by the SMS identification module from the bill payment notification SMS.”)
display a payment interface based at least in part on the activation ([0031] “initiate payment of the bill when the user select option of pay now on the SMS screen, which further displays a payment page through the bill payment application on the mobile communication device wherein the details on the payment page is automatically filled from the payment details extracted by the SMS identification module from the bill payment notification SMS.” And, [0036] “The SMS identification module extracts the payment information from the bill payment SMS received. The payment information comprises vendor details, bill amount, etc.”);
receive a payment action from the payment interface ([0044] “the user is prompted to initiate a payment through the bill payment SMS (208). On initiating the payment a smart bill payment application is invoked (210). Further, the payment information is passed to the smart bill payment application. The smart bill payment application opens a payment page based on the preference of the user. The payment page is automatically filled with the required details. The user is enabled to press the submit button on the payment page to complete the payment.” And, [0019] “The user is enabled to check the information, authorize and validate the payment to complete the payment transaction.”);
Deshmukh teaches activating an application by pressing a selecting a pay now notification and automatically filing in the application payment interface with information but does not explicitly teach the following feature taught by Chan:
[activate] a deep link [for an application] ([0037] “The message can include a deep link. The deep link includes the token with payment data with machine instructions for automatically making the bill payment. The deep link can include or link to bill payment attributes such as the customer identifier, vendor identifier, payment amount, customer account.” And, [0040] “Once the customer clicks on the deep link . . . then the mobile application on user device is launched.” And, [0061] “The deep link opens up the mobile application and after successful authentication, it can direct the user to Bill Payment page with all the details pre-populated.”).
Deshmukh teaches displaying a pre-populated payment interface in response to user activation but does not explicitly teach the following feature taught by Chan:
[display a payment interface based at least in part of the activation of] the deep link, the payment interface populating an identifier for a source account associated with the user identifier at the entity ([0037] “The message can include a deep link. The deep link includes the token with payment data with machine instructions for automatically making the bill payment. The deep link can include or link to bill payment attributes such as the customer identifier, vendor identifier, payment amount, customer account.” And, [0040] “Once the customer clicks on the deep link . . . then the mobile application on user device is launched.” And, [0061] “The deep link opens up the mobile application and after successful authentication, it can direct the user to Bill Payment page with all the details pre-populated.”).
Deshmukh teaches authorizing and validation the payment action but does not explicitly teach the following feature taught by Chan:
transmit the payment action to a remote computing device ([0077] “The CalPay service can receive a confirmation response to the payment verification request approving or denying a payment request . . . the confirmation response can indicate a payment account that the CalPay service can cross-reference to the customer account . . . the payment account may indicate ‘pay with credit card’ or ‘pay with chq account’ and the customer record can include account identifiers for the payment accounts. The CalPay service can update the payment request based on the payment account data.” And, [0078] “The CalPay service can receive a payment confirmation from the Exchange Server and/or other component.” And, claim 1 “receive a payment request.” And, [0064] “The User Device transmits an electronic message with a payment request to Exchange Server.”).
Therefore, it would have been obvious to a person of ordinary skill in the art at the effective filing date to modify Deshmukh to include [display a payment interface based at least in part of the activation of] the deep link, the payment interface populating an identifier for a source account associated with the user identifier at the entity and transmit the payment action to a remote computing device as taught by Chan in order to “embed[] a deep link with payment logic for automatic payment of the bill” (Chan [0060) saving the user time and increasing user convenience.
Claims 2, 8, and 14
As per claims 2, 8, and 14 Deshmukh further teaches:
wherein identifying the eligible condition further comprises:
identifying at least one of:
a plurality of source accounts associated with the user identifier at the entity, the plurality of source accounts comprises the source account, or an amount in the source account has been held at the entity for at least a threshold period of time ([0021] “A plurality of payment methods such as credit cards, debit cards, netbanking, e-wallets etc. are also integrated.” And, [0031] “the E-wallet module is adapted to make payment through preferred mode of payment selected by the user from supported mode of payment on the mobile communication device, wherein the E-wallet module displays available balance in preferred mode of payment, and if balance is low, initiate a recharge application, and make the payment by preferred mode of payment.” And, see account number and owed balance displayed in the notification in Figure 4.).
Claims 3, 9, and 15
As per claims 3, 9, and 15 Deshmukh further teaches:
wherein the payment action comprises the source account, a payment amount, and an identifier for the owed balance ([0043] “the bill payment SMS are identified . . . the payment information including biller name and amount are extracted from the bill payment SMS.” And, see account number and owed balance displayed in the notification in Figure 4.” And, [0018] “the payment information comprises vendor details, bill amount, etc.”).
Claims 4, 10, and 16
As per claims 4, 10, and 16 Deshmukh does not explicitly teach but Chan teaches:
wherein the deep link comprises a reference to the payment interface and an instruction to retrieve the identifier for the source account associated with the user identifier ([0037] “The message can include a deep link. The deep link includes the token with payment data with machine instructions for automatically making the bill payment. The deep link can include or link to bill payment attributes such as the customer identifier, vendor identifier, payment amount, customer account.” And, [0040] “Once the customer clicks on the deep link . . . then the mobile application on user device is launched.” And, [0061] “The deep link opens up the mobile application and after successful authentication, it can direct the user to Bill Payment page with all the details pre-populated.”).
Therefore, it would have been obvious to a person of ordinary skill in the art at the effective filing date to modify the combination of Deshmukh and Chan to include wherein the deep link comprises a reference to the payment interface and an instruction to retrieve the identifier for the source account associated with the user identifier as taught by Chan in order to “embed[] a deep link with payment logic for automatic payment of the bill” (Chan [0060) saving the user time and increasing user convenience.
Claim 20
As per claim 20 Deshmukh further teaches:
determine a time to display the payment action notification based at least in part on profile data associated with the user identifier ([0031] “the scheduler module is adapted to schedule the payment at user selected time and date by interacting with a calendar application in the mobile communication device, when the user selects the remind later icon on the SMS screen and prompt the user to make the payment on the scheduled date and time by providing notification message on SMS screen, wherein the user may select ‘pay now’ or ‘remind later’ option again.” And, [0041] “the scheduler module schedules the payment at a different time by interacting with a calendar application in the mobile communication device. Further, the scheduler module stores the payment information extracted by the SMS identification module.”);
display the payment action notification on the display of the client device at the
determined time ([0031] “the scheduler module is adapted to schedule the payment at user selected time and date by interacting with a calendar application in the mobile communication device, when the user selects the remind later icon on the SMS screen and prompt the user to make the payment on the scheduled date and time by providing notification message on SMS screen, wherein the user may select ‘pay now’ or ‘remind later’ option again.” And, [0041] “the scheduler module schedules the payment at a different time by interacting with a calendar application in the mobile communication device. Further, the scheduler module stores the payment information extracted by the SMS identification module.”);
Claims 5, 11, 17, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent Application Publication 20190050845 (“Deshmukh”) in view of US Patent Application Publication Number 20210295403 (“Chan”) as applied to claims 1, 7, and 13 above, and in further view of US Patent Publication Number 8527405 (“Das”).
Claims 5, 11, and 17
As per claims 5, 11, and 17, Chan discloses directing a user to a pre-populated payment page in response to activation a deep link (Chan [0061]) but Deshmukh and Chan do not explicitly teach the following feature taught by Das:
determine a rewards point amount using a conversion rate based at least in part on the user identifier and the owed balance (Das [col. 9, lines 10-15] “[i]f the balance does not exceed $2000, the early payment rewards system may award 1.5 points per dollar.” Examiner notes that the points per dollar awarded is based on the compared the owed balance to a threshold. And, [col. 3, lines 30-35] “determining rewards for each individual participant account.” And, [col. 4, lines 35-45] “rewards are granted to accounts having a balance above a specific threshold.” And, [col. 10, lines 9-11] “an account and customer identifier.”).
Deshmukh does not explicitly teach but Das teaches:
display the rewards point amount in the payment interface (See Figure 10 element 1060 disclosing a displayed amount of points in to be earned in response to payment).
Therefore, it would have been obvious to a person of ordinary skill in the art at the effective filing date to modify the combination of Deshmukh and Chan to include determine a rewards point amount using a conversion rate based at least in part on the user identifier and the owed balance and display the rewards point amount in the payment interface as taught by Das in order to “encourage[] card holders to pay” (Das [col. 9, lines 25-30]).
Claim 19
As per claim 19, Deshmukh further teaches:
identify one or more source accounts associated with the user identifier ([0021] “A plurality of payment methods such as credit cards, debit cards, netbanking, e-wallets etc. are also integrated.” And, [0031] “the E-wallet module is adapted to make payment through preferred mode of payment selected by the user from supported mode of payment on the mobile communication device, wherein the E-wallet module displays available balance in preferred mode of payment, and if balance is low, initiate a recharge application, and make the payment by preferred mode of payment.” And, see account number and owed balance displayed in the notification in Figure 4.);
determine one or more eligible source accounts based at least in part on the one or more identified source accounts and one or more eligibility indicators ([0031] “enables a user to pay bills directly from bill payment notifications . . . check and compare each message in the SMS inbox with a set of templates in order to identify the incoming SMS as bill payment message, the SMS identification module upon identification of the incoming message as bill payment notification, provides ‘pay now’ and ‘remind later’ icon . . . initiate payment of the bill when the user select option of pay now.” And, [0018] “extracts the payment information from the bill payment SMS received. The payment information comprises vendor details, bill amount.” See account number and owed balance displayed in the notification in Figure 4.);
display on the display of the client device the one or more eligible source accounts ([0031] “initiate payment of the bill when the user select option of pay now on the SMS screen, which further displays a payment page through the bill payment application on the mobile communication device wherein the details on the payment page is automatically filled from the payment details extracted by the SMS identification module from the bill payment notification SMS.” See account number and owed balance displayed in the notification in Figure 4.);
Claims 6, 12, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent Application Publication 20190050845 (“Deshmukh”) in view of US Patent Application Publication Number 20210295403 (“Chan”) in view of US Patent Publication Number 8527405 (“Das”) as applied to claims 5, 11, and 17, and in further view of US Patent Publication Number 9972047 (“Elliott”).
Claims 6, 12, and 18 As per claims 6, 12, and 18, Deshmukh does not explicitly teach but Elliott teaches:
receive an entry of a payment amount in the payment interface ([col. 12, lines 35-40] “User interface may also include payment inputs.” And, [col. 14, lines 1-5] “[u]ser interface may also include a rewards points payment input and an account payment input.” And, [col. 19, lines 20-25] “payment inputs and account input may be text input boxes for the customer to type in dollar amounts to allocate to each rewards program.”).
Deshmukh does not explicitly teach but Elliott teaches:
update the rewards point amount in the payment interface based at least in part on the payment amount and the conversion rate ([col. 20, liens 1-7] “points needed display, which may each dynamically change in response to text entries from the customer into rewards program payment inputs. Total points needed display may also correspond to the purchase amount of the transaction.” And, [col. 11. Liens 45-50] “conversion data associated with a particular rewards program may be a simple ratio or percentage for converting between rewards points and cash.”).
Therefore, it would have been obvious to a person of ordinary skill in the art at the effective filing date to modify the combination of Deshmukh, Chan, and Das to include receive an entry of a payment amount in the payment interface and update the rewards point amount in the payment interface based at least in part on the payment amount and the conversion rate as taught by Elliott because “[m]odifying one allocation in response to a change in another may give the customer a better sense of how he or she should use rewards points and accounts to pay for a purchase and may be of great benefit to the customer in making a financial decision” ([col. 11, lines 45-50]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US Patent Application Publication Number 20130080270 (“Ronca”) discloses a rewards points field for providing user input to change the prioritization of rewards points when recommending an account
US Patent Application Publication Number 20200118115 (“Zarakas”) discloses a transaction terminal may output an indication of whether the transaction is approved or declined, and may complete the transaction if the transaction is approved and provide earned reward points
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALLAN J WOODWORTH, II whose telephone number is (571)272-6904. The examiner can normally be reached on Mon-Fri 9:00-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, Ilana Spar can be reached at 571-270-7537. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ALLAN J WOODWORTH, II/Primary Examiner, Art Unit 3622
Prosecution Insights