DETAILED ACTION
This Office Action is in response to the communication filed on 3/2/2026.
Claims 1-20 are pending.
Claims 1, 8 and 15 have been amended.
Claims 1-20 are rejected.
The Examiner cites particular sections in the references as applied to the claims below for the convenience of the applicant(s). Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant(s) fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
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 .
Notes
From the claim language, it is not clear if the software applications designations (plurality, first, second, trusted) are intended to be subsets of the same group, completely separate groups, or if they have some partial overlap. For the purposes of examining they could be interpreted to be identical.
General Note
The claims recite “interaction request” and “interaction data”, please clarify whether these are the same or different.
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 1, 8 and 15 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 applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1, 8 and 15 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 applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1, 8 and 15 recites the limitation "the interaction request" in the amended limitation. There is insufficient antecedent basis for this limitation in the claim, specifically multiple antecedent basis exist. “an interaction request to the plurality of software applications without performing an interaction requested by the interaction request should read “an interaction request to the plurality of software applications without performing [[an]] the interaction requested by the interaction request” or similar.
Regarding claims 1, 8 and 15, recite the phrase "without performing an interaction requested by the interaction request, " renders the claim indefinite because, without further indications, it is a contradictory statement,
For example, If a user’s interaction comprises requesting pre-authentication the pre-authentication (1) occurs in response to a determination and also (2) cannot occur according to the amended claim language. Therefore under BRI, this is contradictory.
Dependent claims are also rejecting for inheriting the deficiencies set forth above.
Response to Arguments
Applicant's arguments filed 3/2/2026 have been fully considered but they are not persuasive.
Applicant argues on page 11 of remarks that Louboutin does not teach “in response to determining that the first software application has previously communicated with one or more of the first set of trusted software applications, the processor is configured to pre-authenticate the first software application to allow the first software application to communicate an interaction request to the plurality of software applications”
Examiner disagrees, Louboutin teaches process 300 where “in response to” determining that the ID is not on the known-good list, meaning that the ID has not been previously approved (Fig. 3-306), an authentication operation is performed (Fig. 3-308) to add the ID to the known-good list (Fig. 3-314). Therefore Louboutin teaches the claimed limitation.
Applicant further argues that Louboutin does not teach “in response to determining that the first software application has previously communicated with one or more of the first set of trusted software applications, the processor is configured to pre-authenticate the first software application to allow the first software application to communicate an interaction request to the plurality of software applications without performing an interaction requested by the interaction request”.
Examiner disagrees, Louboutin teaches this concept in at least paragraph 0115. Where receiving and acting on messages (the requested interaction) is blocked until the authentication is performed. Therefore the claim limitation of without performing an interaction requested by the interaction request is satisfied because the interaction requested (receiving and acting on messages) if not being performed until pre-authentication is complete.
Applicant argues on pages 11-12 of remarks that Louboutin's does not teach performing the authentication operation if the ID is not on the whitelist. Examiner asserts that as cited below and argued above, Louboutin explicitly teaches this.
Applicant argues on page Louboutin does not disclose in response to determining that the first software application has been successfully onboarded, perform the interaction requested by the interaction request based on the pre-authenticated data stored in the memory. However Reis teaches this this limitation. (Reis [Col 26 line 25 – Col 28 line 5, Fig. 8-806] teaches processing a transaction request in response to determining that the requester is pre-authenticated, using the pre-authentication data)
Additionally Louboutin teaches this limitation, see fig. 3-308 [Wingdings font/0xE0] 3-316.
Applicant argues that dependent claims are in condition for allowance by virtue of the independent claims, however Examiner does not find the independent claims allowable.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries 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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Reis (U.S. 12147989) in view of Louboutin (U.S. 20140196142).
Regarding claim 1,
Reis discloses: A system comprising: (Reis [Col 10 line 5-17] Systems and methods)
a memory operable to store: (Reis [Col 12 line 10-44] Memory; Processor)
a plurality of software applications configured to manage interaction data; (Reis [Col 3 line 10 – Col 4 line 23, Col 17 line 22-59, Col 24 line 10 – Col 25 line 26]; [Fig. 7-702, Fig. 8-802] teaches software application which manage interaction data)
known identification data associated with a first set of trusted software applications that are approved to communicate with the plurality of software applications; (Reis [Col 3 line 10 – Col 4 line 23, Col 17 line 22-59, Col 24 line 10 – Col 25 line 26]; [Fig. 7-708, Fig. 8-806] teaches previous authentication records, which contain known identification data of approved devices)
historical communication data associated with the first set of trusted software applications; (Reis [Col 3 line 10 – Col 4 line 23, Col 17 line 22-59, Col 24 line 10 – Col 25 line 26]; [Fig. 7-708, Fig. 8-806] teaches previous authentication records (historical communication data associated with trusted devices)
a processor operably coupled to the memory, the processor configured to: (Reis [Col 12 line 10-44] Memory; Processor)
receive an onboarding request from a first software application, wherein the onboarding request includes a request to communicate between the first software application and the plurality of software applications, wherein the onboarding request comprises: (Reis [Col 3 line 10 – Col 4 line 23, Col 17 line 22-59, Col 24 line 10 – Col 25 line 26]; [Fig. 7-704, Fig. 8-802] teaches receiving a command requesting two-factor authentication (onboarding request, requesting communication privileges to communicate with various applications (software))
identification data associated with the first software application; and (Reis [Col 3 line 10 – Col 4 line 23, Col 17 line 22-59, Col 24 line 10 – Col 25 line 26]; [Fig. 7-704, Fig. 8-802]; [Col 22 line 50 – Col 23 line 32] teaches the request includes a device ID)
historical communication data associated with the first software application; (Reis [Col 3 line 10 – Col 4 line 23, Col 17 line 22-59, Col 24 line 10 – Col 25 line 26]; [Fig. 7-706, Fig. 8-804]; teaches a database storing existing authenticated records (historical communication data) which were generated by previous SDK execution(s) and using them for “chain of authentication” which uses a probabilistic model to determine between first probabilistic signals received from the first application and second probabilistic signals received from the second application)
determine whether the first software application has previously been approved to communicate with the plurality of software applications by comparing the identification data associated with the first software application to the known identification data associated with the first set of trusted software applications; (Reis [Col 3 line 10 – Col 4 line 23, Col 5 line 35 – Col 7 line 55, Col 17 line 22-59 – Col 18 line 49, Col 24 line 10 – Col 25 line 26]; [Fig. 7-708, Fig. 8-806] teaches a correlation component which determine if the requesting device (first software application) is a trusted device using “chain of authentication” by determining if the device has previously been authenticated and remains valid by comparing existing authentication records to the current authentication request and if approval is affirmed, no longer requiring 3DS authentication if not affirmed, requiring 3Ds authentication)
in response to determining that the first software application has not been previously approved to communicate with the plurality of software applications, the processor is configured to… (Reis [Col 3 line 10 – Col 4 line 23, Col 17 line 22-59, Col 24 line 10 – Col 25 line 26]; [Fig. 7-710, 7-712]; teaches performing two-factor authentication in response to failing to find an existing authentication record, requiring 3Ds authentication)
process the interaction data using the plurality of software applications to generate pre-authenticated data; and (Reis [Col 3 line 10 – Col 4 line 23, Col 17 line 22-59, Col 24 line 10 – Col 25 line 26]; [Fig. 7-712, Fig. 8-806]; teaches generating pre-authentication records, and storing the records in memory, in order to authenticate future transactions)
store the pre-authenticated data in the memory; (Reis [Col 3 line 10 – Col 4 line 23, Col 17 line 22-59, Col 24 line 10 – Col 25 line 26, Col 28 line 9 – Col 10 line 48]; [Fig. 9-908]; teaches generating pre-authentication records, and storing the records in memory, in order to authenticate future transactions)
in response to determining that the first software application has been successfully onboarded, perform the interaction requested by the interaction request based on the pre-authenticated data stored in the memory. (Reis [Col 26 line 25 – Col 28 line 5, Fig. 8-806] teaches processing a transaction request in response to determining that the requester is pre-authenticated, using the pre-authentication data)
While Reis discloses correlating with prior or existing records via probabilistic signals (GPS, time, behavioral, transaction), it does not explicitly teach comparison of "historical communication data associated with the software application" to historical communication data associated with set of trusted applications, Reis does not explicitly disclose: determine whether the first software application has previously communicated with one or more of the first set of trusted software applications by comparing the historical communication data associated with the first software application to the historical communication data associated with one or more of the first set of trusted software applications;
in response to determining that the first software application has previously communicated with one or more of the first set of trusted software applications, the processor is configured to pre-authenticate the first software application to allow the first software application to communicate an interaction request to the plurality of software applications… wherein the interaction request comprises the interaction data;
However, in the same field of endeavor Louboutin discloses: determine whether the first software application has previously communicated with one or more of the first set of trusted software applications by comparing the historical communication data associated with the first software application to the historical communication data associated with one or more of the first set of trusted software applications; (Louboutin [Fig. 3-306, 0004-0012, 0029, 0060-0069] teaches determining authentication using on a known-good identifiers list (whitelist) which is a list identifying devices which have previously established authorized communications; the known-good list is based on identification information which is received when communication, including past communications allowing the host device and accessory to resume communication more quickly after an interruption; [[)
in response to determining that the first software application has previously communicated with one or more of the first set of trusted software applications, the processor is configured to pre-authenticate the first software application to allow the first software application to communicate an interaction request to the plurality of software applications without performing an interaction requested by the interaction request, wherein the interaction request comprises the interaction data; (Louboutin [Fig. 3-308, 3-310, 0004-0012, 0019, 0029, 0060-0069, 0078-0088] teaches when the authentication operation has succeeded (previous trusted communication) then communication can proceed; [0062] At block 304, host device 100 can compare the accessory identifier to identifiers on known-good list 142. At block 306, if a match is not found, then at block 308, host device 100 can invoke authentication logic 140 to perform an authentication operation; [0063] Block 308 can also include exchanging other configuration-related messages, e.g., information related to the functionality the accessory intends to invoke during interoperation with the host device; [0115] In some embodiments, while authentication is in progress, the accessory can be blocked from sending any messages not related to authentication)
Reis and Louboutin are analogous art because they are from the same field of endeavor multi-factor authentication.
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Reis and Louboutin before him or her, to modify the method of Reis to include the known-good list for of Louboutin because it will allow the host device and accessory to resume communication more quickly after an interruption.
The motivation for doing so would be [“the first device can obtain configuration information from the second device. If the authentication operation completes successfully, the first device can store the configuration information in association with the unique device identifier of the second device. When a known-good device (i.e., a device whose unique device identifier is included in the list of known-good device identifiers) reconnects, the first device can access the stored configuration information. Thus, a known-good device need not re-provide its configuration information upon reconnecting to a device to which it has previously connected”] (Paragraph 0006 by Louboutin)].
Therefore, it would have been obvious to combine Louboutin and Louboutin to obtain the invention as specified in the instant claim.
Additionally, claim 8 discloses: A method comprising: (Reis [Col 10 line 5-17] Systems and methods)
Additionally, claim 15 discloses: A non-transitory computer-readable medium that stores instructions that when executed by a processor, cause the processor to: (Reis [Col 49 line 40-63] non-transitory computer storage media)
Regarding claims 2, 9, and 16,
Reis in view of Louboutin discloses: The system of claim 1, wherein the processor is further configured to:
receive an indication that the first software application is onboarded; and in response to receiving the indication that the first software application is onboarded, process the pre-authenticated data to post the interaction request. (Reis [Col 3 line 10 – Col 4 line 23, Col 5 line 35 – Col 7 line 55, Col 17 line 22 – Col 18 line 49, Col 24 line 10 – Col 25 line 26]; [Fig. 7-706, 7-708, Fig. 8-806] teaches a correlation component which determine if the requesting device (first software application) is a trusted device using “chain of authentication” by determining if the device has previously been authenticated and remains valid by comparing existing authentication records to the current authentication request and if approval is affirmed, no longer requiring 3DS authentication)
Regarding claims 3, 10, and 17,
Reis in view of Louboutin discloses: The system of claim 1, wherein the memory is further operable to store known identification data associated with a second set of trusted software applications; and (Reis Col 3 line 27- Col 4 line 23, Col 5 line 35 – Col 7 line 55, Col 17 line 22 – Col 18 line 49, Col 24 line 10 – Col 25 line 26, Fig. 7-706, Fig. 8-804]; teaches using third party applications to lookup known identification data, indicating trust)
wherein the processor is further configured to:
in response to determining that the first software application has not previously communicated with one or more of the first set of trusted software applications, the processor is configured to determine whether the identification data associated with the first software application matches the known identification data associated with one or more of the second set of trusted software applications; and (Reis [Col 5 line 35 – Col 7 line 55, Col 17 line 22 – Col 18 line 49, Col 33- Col 24 line 46, Col 28 line 9 – Col 29 line 48, Fig. 8-804] teaches that in response to not finding an existing authentication record, two-factor authentication is performed, once it is performed the authentication record is stored and the authentication is performed using the new authentication record; “at block 906… generating the authentication record may be based at least in part on failing to identify the existing authentication record”) Note: adding a new trusted application (just authenticated new application) creates a 2nd set of trusted applications.
in response to determining that the identification data associated with the first software application matches the known identification data associated with one or more of the second set of trusted software applications, the processor is configured to pre-authenticate the first software application to allow the first software application to communicate the interaction request to the plurality of software applications. (Reis [Col 5 line 35 – Col 7 line 55, Col 17 line 22 – Col 18 line 49, Col 33- Col 24 line 46, Col 28 line 9 – Col 29 line 48, Fig. 7-708, Fig. 8-806] teaches that in response to not finding an existing authentication record, two-factor authentication is performed, once it is performed the authentication record is stored and the authentication is performed using the new authentication record; “At block 908, the process 900 may include storing the authentication record indicating the authentication to authenticate a future payment transaction by at least one of the first application or the second application”)
Regarding claims 4, 11, and 18,
Reis in view of Louboutin discloses: The system of claim 3, wherein in response to determining that the first software application does not match the known identification data associated with one or more of the second set of trusted software applications, the processor is configured to deny the onboarding request. (Reis [Col 5 line 35 – Col 7 line 55, Col 17 line 22 – Col 18 line 49, Col 33- Col 24 line 46, Col 28 line 9 – Col 29 line 48, Fig. 7-710, 7-712] teaches that in response to not finding an existing authentication record, two-factor authentication is performed) Note: the onboarding request is denied (until/unless two-factor authentication is performed and approved
Regarding claims 5, 12, and 19
Reis in view of Louboutin discloses: The system of claim 1, wherein the processor is further configured to:
compare the historical communication data associated with the first software application to the historical communication data associated with one or more of the first set of trusted software applications using a secure multi-party computation protocol. (Reis [Col 5 line 35 – Col 7 line 55, Col 17 line 22 – Col 18 line 49, Col 33- Col 24 line 46, Col 28 line 9 – Col 29 line 48, Fig. 7-706, Fig. 8-804] teaches first and second third-party applications where records of previous communications may be stored and retrieved for authentication new devices)
Regarding claims 6 and 13,
Reis in view of Louboutin discloses: The system of claim 1, wherein the processor is further configured to:
receive a second onboarding request for a second software application, wherein the second onboarding request includes a second request to communicate between the second software application and the plurality of software applications, wherein the second onboarding request comprises second identification data associated with the second software application; (Reis [Col 5 line 35 – Col 7 line 55, Col 17 line 22 – Col 18 line 49, Col 33- Col 24 line 46, Col 28 line 9 – Col 29 line 48, Fig. 7-704, Fig. 9-902] teaches receiving a command requesting two-factor authentication (onboarding request, requesting communication privileges to communicate with various applications (software); [Col 22 line 50 – Col 23 line 32] teaches the request includes a device ID)
determine whether the second software application has previously been approved to communicate with the plurality of software applications by comparing the second identification data associated with the second software application to the known identification data associated with the first set of trusted software applications; (Reis [Col 5 line 35 – Col 7 line 55, Col 17 line 22 – Col 18 line 49, Col 33- Col 24 line 46, Col 28 line 9 – Col 29 line 48, Fig. 7-708, Fig. 9-904] teaches a correlation component which determine if the requesting device (first software application) is a trusted device using “chain of authentication” by determining if the device has previously been authenticated and remains valid by comparing existing authentication records to the current authentication request and if approval is affirmed, no longer requiring 3DS authentication if not affirmed, requiring 3Ds authentication)
in response to determining that the second software application is approved to communicate with the plurality of software applications, the processor is further configured to receive a second interaction request from the second software application, wherein the second interaction request comprises second interaction data; and (Reis [Col 5 line 35 – Col 7 line 55, Col 17 line 22 – Col 18 line 49, Col 33- Col 24 line 46, Col 28 line 9 – Col 29 line 48, Fig. 7-708, Fig. 8-806] teaches a correlation component which determine if the requesting device (first software application) is a trusted device using “chain of authentication” by determining if the device has previously been authenticated and remains valid by comparing existing authentication records to the current authentication request and if approval is affirmed, no longer requiring 3DS authentication)
process the second interaction data to post the second interaction request. (Reis[Col 5 line 35 – Col 7 line 55, Col 17 line 22 – Col 18 line 49, Col 33- Col 24 line 46, Col 28 line 9 – Col 29 line 48, Fig. 7-708, Fig. 8-806] teaches generating pre-authentication records, and storing the records in memory, in order to authenticate future transactions)
Regarding claims 7, 14, and 20,
Reis in view of Louboutin discloses: The system of claim 1, wherein the plurality of software applications comprise a pre-authentication application, wherein the pre-authentication application is configured to generate the pre-authenticated data; and (Reis [Col 5 line 35 – Col 7 line 55, Col 17 line 22 – Col 18 line 49, Col 33- Col 24 line 46, Col 28 line 9 – Col 29 line 48, Fig. 9-906, 9-908] teaches generating pre-authentication records, and storing the records in memory, in order to authenticate future transactions)
wherein the processor is further configured to store the pre-authenticated data in a pre-authenticated area in the pre-authentication application. (Reis [Col 5 line 35 – Col 7 line 55, Col 17 line 22 – Col 18 line 49, Col 33- Col 24 line 46, Col 28 line 9 – Col 29 line 48, Fig. 9-906, 9-908] teaches generating pre-authentication records, and storing the records in memory, in order to authenticate future transactions)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's
disclosure.
Gilbey 2016-9-12 (U.S. 20170083902) teaches a platform is provided for receiving and processing resource request data, and automating the authorization process involved with resource requests. The resource platform may be leveraged by one or more entities via secure communication interface through the conversation of electronic resource request data to industry standard formatting as well as formatting for multiple digital channel types. Authorization of electronic resource requests may include intelligent user configuration for convenient authentication via the use of multiple authenticated users.
Zhu 2009-3-6 (U.S. 20100228982) teaches requiring a client application requesting data to authenticate itself to an application providing the data. Such authentication requests can be redundant, especially in the case of stateless network protocols. When a full authentication is performed, a conversation identifier and one or more encryption keys can be agreed upon. Subsequent authentication requests can be answered with a fast reconnect token comprising the conversation identifier and a cryptographically signed version of it using the one or more encryption keys. Should additional security be desirable, a sequence number can be established and incremented in a pre-determined or a random manner to enable detection of replayed fast reconnect tokens. If the recipient can verify the fast reconnect token, the provider can be considered to have been authenticated based on the prior authentication. If an aspect of the fast re-authentication should fail, recourse can be had to the original full authentication process.
Divens 2002-5030 (U.S. 20030226036 ) teaches a method and apparatus for enabling a client to use a single set of credentials to access multiple secure applications at servers. A proxy authentication application at the server intercepts all requests for applications that require authentication, and initiates an authentication procedure with a proxy authentication application installed at the client. User credentials provided by the client authenticator are used by the server authenticator to determine the access credentials that should be forwarded to the server application on behalf of the users. The method allows per-user and per-application authentication decisions to be made at a system level rather than at an application level, even for legacy applications that are designed to require authentication at the application level, without modification to legacy client or server applications.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 THOMAS A CARNES whose telephone number is (571)272-4378. The examiner can normally be reached Monday-Friday.
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, Shewaye Gelagay can be reached at (571) 272-4219. 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.
THOMAS A. CARNES
Examiner
Art Unit 2436
/THOMAS A CARNES/Examiner, Art Unit 2436 /SHEWAYE GELAGAY/Supervisory Patent Examiner, Art Unit 2436