DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on -- has been entered.
Claim Objections
Claims 1,10 and 18 are objected to because of the following informalities:
As pr claims 1,10 and 18, those claims recite the phase “aggregator access profile…”, It would have been aggregator specifying application programing interface (API).
Appropriate correction is required.
Applicant argued in the remark that an aggregator access profile specifying application programming interface (API) access to be granted to a data aggregator with respect to one or more APIs, each of the one or more APIs being uniquely associated with a selected account function or account data type.
However, O’kennedy discloses an aggregator (fig.1, API gateway platform and col 1, lines 45-50 aggregates or selects over a small set of similar APIs by building services or components that physically implement logic to do the aggregation and The aggregation service 310) access profile specifying application programming interface (API) access to be granted to a data aggregator with respect to one or more APIs, each of the one or more APIs being uniquely associated with a selected account function or account data type (col 7, lines 28-33 the API Gateway Platform 110 may communicate with the custom service layer 112 to access core capability services and/or utilities. The custom service layer 112 may selectively communicate with external APIs 212 of downstream third party provider services 104 and col 7, lines 45-50 (31) Aggregation-style APIs—may be a category or style of APIs where existing services are being provided by external APIs 212 from multiple API providers 214 selected from among the third party provider services 104, and col 8, lines 17-24 a user request directed to a specific third party provider service, such as a request to access a user's existing account, the specific target API provider 214 and corresponding API 212, associated with the user's account may be identified by the system 100 based on provider specific information associated with the user request. Wherein the user access is being specific API 212 by the specific target API provider 214 for the account access , FIG. 8 is an example of operation of the extensible single point orchestration system in the application of key management services accessing a 3rd party communication service. Key management services may be initiated by the system when the API gateway 110 is provided with an API services call message by a application 802, instead of the application providing a service request message, which would initiate either the aggregation service 310 or the selection service 312. Since the application already knows the specific external API to which the call is directed, and has identified the specific external API with an API services call message, key management services may be initiated in the system. However, if the external API requires an API key in order to respond to the API services call message, the key management service 318 may be used to supply an appropriate sub-key to avoid the user being forced to manage and apply the proper API key for the target external API. Without the appropriate API key being included with the API service call message, the external API will not respond. And col 8, lines 1-20 Selection-style APIs—may be a category or style of API that is called where the API consumer (user/client) desires to perform an operation with only one of the API providers 214, such as credentialed individual services service providers 120 (FIG. 1). The selection-style APIs may be from service providers 104 capable of providing similar or unrelated services, such as credentialed individual services service providers 120 (FIG. 1). The APIs 212 may be for individual requests, or alternatively may be the same or a similar API to the APIs of the aggregation-style API category. Individual selection of an API 212 of an API provider 214 from the among the third party provider services 104 may be determined by the system 100 via provider specific information passed by the client/user (e.g. input parameters, request headers, security tokens, and/or other information associated with the user/client interaction with the system) ).
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.
Claim(s) 1-5, 7-14, and 16-19 are rejected under 35 U.S.C. 103 as being unpatentable over Hockey et al. US 11,050,729 B2 hereafter Hockey and O’kennedy et al US 9,921,894.
As to Claim 1
Hockey discloses:
A computing platform configured for processing a data request (Hockey, Fig. 1, 100, Col. 35, ll. 1-3, The API service 110 can provide an interface into a variety of information and action resources , as provided by the system 100.) the computing platform comprising: a non-transient computer-readable storage medium having instructions embodied thereon; (Fig. 11, Col. 51, ll. 20-35, “FIG . 11 is an architecture diagram of the system 100 … implemented by a computer readable storage medium 1105 ( e.g. , a non - transitory computer readable storage medium) . Col. 52 ll. 5-7, “…of these software programs , the respective machine - executable instructions…”) and
one or more processors configured to execute the instructions (Hockey Fig. 11, Col. 52, ll. 5-8, “… instructions are accessed by at least one of processors 1101A - 1101N ( of the processing unit 1199 ) via the bus 1102”) to: receive, at the computing platform and from a user device associated with a user, a data transfer request including data transfer instructions associated with the data transfer; (Hockey Col. 54, ll. 65-67, “In action 1a , the user computing device 1214 interacts with the external user account system … when a user of the user computing device 1214 provides an input indicating an intent to provide authorization to a user account. Hockey Col. 55, ll. 10-16,external user account system 1206. Col. 5, ll. 41-50 “… the normalized financial service request is a financial transfer request , wherein the normalized financial service request specifies information [i.e. the instructions,] identifying a source financial service system , a source account of the source financial service system , a destination financial service system , a destination account of the destination financial service system , and a transaction amount…” Hockey Col. 55, ll. 10-16, “Accordingly , in an embodiment , the permissions plug-in 1211 may be executed by the user computing device 1214 , which may present an interactive user interface to the user ( as described in further detail below in reference to FIG . 18 )”)
obtain, by the computing platform, an aggregator access profile specifying application programming interface (API) access to be granted to a data aggregator with respect to one or more APIs; (Fig. 1. 131, Institution interface module, Col. 36, ll. 30-43, “available in the system. The institution interface module may include a set of rules and processes of a particular institution. ... The institution interface module can additionally include institution protocol submodule , which defines a mapping between provided API 110 functionality and the form and mode of communication with the external institution…” )
obtain, by the computing platform, a user account authorization token specifying access to be granted to the data aggregator with respect to one or more user accounts; (“Col. 36, ll. 4-13, “Some of those properties may be automatically generated , may be provided from the institution during negotiating registration, may be properties of the application that is being simulated, and / or may include any suitable identifying and authenticating information . The properties may include a unique user identifier code , an authentication token , a MAC address e.g. , a MAC address of a user device 171 or 172 ) , or any suitable information.”)
determine, by the computing platform, access permissions associated with the data transfer instructions based on a combination of the aggregator access profile and the user account authorization token; (Col. 44, 58-67“The method may additionally include verifying transaction conditions during one or more stages . Transaction conditions may be used to take any suitable action . The available actions can include permitting a transaction or preventing a transaction.” “Col. 36 ll. 30-43 … institution . The institution interface module may include a proxy sub - module that defines how the institution recognizes and / or authenticates a particular application. … some may depend on asymmetric cryptography tokens , and others may generate encrypted tokens.” …) and
transmit, by the computing platform and to the data aggregator, an access notification based on the determined access permissions, the access notification specifying the combination of the one or more APIs and the one or more user accounts to which the data aggregator is granted access. (Col. 34, ll. 16-26, The system 100 functions to provide a normalized interface ( e.g. , API service 110 ) to the one or more external user account systems ( e.g. , external user account systems 141 , 142 , and 143 ) . The system 100 enables access to a user [via a] virtualized “ image ”or digital simulation of an application instance is maintained in the application proxy system 120 and used to access the unexposed API ( e.g. , APIs 161 , 162 , and 163 ) of the external user account system.” Col. 44, ll. 58-67 “The method may additionally include verifying transaction conditions …. Transaction conditions may be used to take any suitable action . The available actions can include permitting a transaction or preventing a transaction. Additionally, the action can include sending a notification. The notification can include an email, text message, a platform message, a phone call, or any suitable notification. The action may additionally include triggering a programmatic event.”) Examiner submits that the API, as the means of access to the account information i.e. “permitting a transaction”, is a “transaction condition” that may generate a notification. ]
Hockey does not disclose an aggregator access profile specifying application programming interface (API) access to be granted to a data aggregator with respect to one or more APIs, each of the one or more APIs being uniquely associated with a selected account function or account data type.
However, O’kennedy discloses an aggregator (fig.1, API gateway platform and col 1, lines 45-50 aggregates or selects over a small set of similar APIs by building services or components that physically implement logic to do the aggregation and The aggregation service 310) access profile specifying application programming interface (API) access to be granted to a data aggregator with respect to one or more APIs, each of the one or more APIs being uniquely associated with a selected account function or account data type (col 7, lines 28-33 the API Gateway Platform 110 may communicate with the custom service layer 112 to access core capability services and/or utilities. The custom service layer 112 may selectively communicate with external APIs 212 of downstream third party provider services 104 and col 7, lines 45-50 (31) Aggregation-style APIs—may be a category or style of APIs where existing services are being provided by external APIs 212 from multiple API providers 214 selected from among the third party provider services 104, and col 8, lines 17-24 a user request directed to a specific third party provider service, such as a request to access a user's existing account, the specific target API provider 214 and corresponding API 212, associated with the user's account may be identified by the system 100 based on provider specific information associated with the user request. Wherein the user access is being specific API 212 by the specific target API provider 214 for the account access , FIG. 8 is an example of operation of the extensible single point orchestration system in the application of key management services accessing a 3rd party communication service. Key management services may be initiated by the system when the API gateway 110 is provided with an API services call message by a application 802, instead of the application providing a service request message, which would initiate either the aggregation service 310 or the selection service 312. Since the application already knows the specific external API to which the call is directed, and has identified the specific external API with an API services call message, key management services may be initiated in the system. However, if the external API requires an API key in order to respond to the API services call message, the key management service 318 may be used to supply an appropriate sub-key to avoid the user being forced to manage and apply the proper API key for the target external API. Without the appropriate API key being included with the API service call message, the external API will not respond. And col 8, lines 1-20 Selection-style APIs—may be a category or style of API that is called where the API consumer (user/client) desires to perform an operation with only one of the API providers 214, such as credentialed individual services service providers 120 (FIG. 1). The selection-style APIs may be from service providers 104 capable of providing similar or unrelated services, such as credentialed individual services service providers 120 (FIG. 1). The APIs 212 may be for individual requests, or alternatively may be the same or a similar API to the APIs of the aggregation-style API category. Individual selection of an API 212 of an API provider 214 from the among the third party provider services 104 may be determined by the system 100 via provider specific information passed by the client/user (e.g. input parameters, request headers, security tokens, and/or other information associated with the user/client interaction with the system) ).
Hockey and O’Kennedy are both considered to be analogous to the claimed invention because they are in the same field of aggregation of the APIs.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Hockey to incorporate the teachings of O’Kennedy and provide selection of the APIs.
Doing so would provide specific API communication for account, thereby increasing the protection for the account.
As to Claim 2
Hockey and O’Kennedy discloses The computing platform of claim 1.
In addition, Hockey discloses:
wherein the user account authorization token is based on account access permissions specified by the user. (“Col. 36, ll. 4-13, “Some of those properties may be automatically generated , may be provided from the institution during negotiating registration, may be properties of the application that is being simulated, and / or may include any suitable identifying and authenticating information . The properties may include a unique user identifier code , an authentication token , a MAC address e.g. , a MAC address of a user device 171 or 172 ) , or any suitable information. suitable information . When a request is made to a bank on behalf of a user , the properties of the proxy instance may be invoked to gain access to the institution on behalf of the associated user .”) Examiner submits, that the “properties” in their entirety are claimed authorization token. The “properties” give access, and thus act as an authorization token. This is distinguishable from the authentication token of Hockey which is not mapped to the claimed authorization token.
As to Claim 3
Hockey and O’Kennedy discloses The computing platform of claim 1.
In addition, Hockey discloses:
wherein the aggregator access profile is based on permissions specified by an institution associated with the one or more APIs. (Fig. 1. 131, Institution interface module, Col. 36, ll. 30-43, “available in the system. The institution interface module may include a set of rules and processes of a particular institution. ... The institution interface module can additionally include institution protocol submodule , which defines a mapping between provided API 110 functionality and the form and mode of communication with the external institution…” Col. 70, ll. 39-44, “At block 1860 , the token generated by the permissions management system 1204 and / or the external user account system 1206 is communicated to the external user-facing system / application 1208 , either directly , via the permissions plug-in 1210 , and / or via the permissions management system 1204 ( as described above in reference to FIG . 16A ) .”) Examiner submits that Fig. 1 shows the institution interface module interfaces with a Bank and its respective API, e.g. 131, 141, and 161.
As to Claim 4
Hockey and O’Kennedy discloses The computing platform of claim 1.
In addition, Hockey discloses:
wherein the one or more processors are further configured to execute the instructions to: obtain, by the computing platform, an expanded user account authorization token specifying access to be granted to the data aggregator with respect to one or more user accounts and with respect to one or more data types;
(Hockey, Col. 64, l. 67—Col.65 l. 5, “128 may send a request to the trusted third - party processor system 1212 for execution of a transaction ( which request may include , e.g. , the token and / or other account information); the trusted third - party processor system 1212 may optionally communicate with the permissions management system 1204 to determine that the external user – facing system / application 1208 is authorized to cause the transaction to be executed ( e.g. , permissions may be checked , an account balance may be checked , etc. ) ; and the trusted ”) Examiner submits this matches Applicant’s definition of “expanded” given in Applicant’s Spec 0023, “an expanded user account authorization token may specify that a user grants access only to personal accounts, and only to account transactions, but not to account balances.” The “account balance” is an example of a data type.
determine, by the computing platform, access permissions associated with the data transfer instructions based on the combination of the aggregator access profile and the expanded user account authorization token; (Hockey Col. 65, ll. 8-13, “account system 1206 ) . In this implementation , the permissions management system 1204 may generate the token after accessing account information from the external user account system 1206 ( e.g. , as described herein ) and / or in response to a request received from the external user – facing system /application 1208 .”) and
transmit, by the computing platform and to the data aggregator, the access notification based on the determined access permissions, the access notification specifying the combination of the one or more APIs and the one or more user accounts (Col. 34, ll. 16-26, The system 100 functions to provide a normalized interface ( e.g. , API service 110 ) to the one or more external user account systems ( e.g. , external user account systems 141 , 142 , and 143 ) . The system 100 enables access to a user [via a] virtualized “ image ”or digital simulation of an application instance is maintained in the application proxy system 120 and used to access the unexposed API ( e.g. , APIs 161 , 162 , and 163 ) of the external user account system.” Col. 44, ll. 58-67 “The method may additionally include verifying transaction conditions …. Transaction conditions may be used to take any suitable action . The available actions can include permitting a transaction or preventing a transaction . Additionally , the action can include sending a notification . The notification can include an email, text message , a platform message , a phone call , or any suitable notification . The action may additionally include triggering a programmatic event.”) Examiner submits that the API, as the means of access to the account information, is a “transaction condition” that may generate a notification.
and the one or more data types to which the data aggregator is granted access. Hockey, Col. 64, l. 67—Col.65 l. 5, “128 may send a request to the trusted third - party processor system 1212 for execution of a transaction ( which request may include , e.g. , the token and / or other account information); the trusted third - party processor system 1212 may optionally communicate with the permissions management system 1204 to determine that the external user – facing system / application 1208 is authorized to cause the transaction to be executed ( e.g. , permissions may be checked , an account balance may be checked , etc. ) ; and the trusted ”) Examiner submits the “account balance” is an example of a data type.
As to Claim 5
Hockey and O’Kennedy discloses The computing platform of claim 1.
In addition, Hockey discloses:
wherein the one or more processors are further configured to execute the instructions to: obtain, by the computing platform, an application-specific user account authorization token specifying access to be granted to a third party application with respect to an application-specific set of one or more user accounts;
(“Col. 36, ll. 4-13, “Some of those properties may be automatically generated , may be provided from the institution during negotiating registration, may be properties of the application that is being simulated, and / or may include any suitable identifying and authenticating information . The properties may include a unique user identifier code , an authentication token , a MAC address e.g. , a MAC address of a user device 171 or 172 ) , or any suitable information.” Col 64, ll. 47-53, “… multiple tokens may be used in the actions described above . For example , the token stored by the trusted third party processor system 1212 may differ from the token shared with the external user - facing system/application 1208 e.g. , a different unique identifier may be shared with the external user-facing system/application 1208.)
determine, by the computing platform, access permissions associated with the data transfer instructions based on the combination of the aggregator access profile and the application-specific user account authorization token; and (Hockey Col. 65, ll. 8-13, “account system 1206 ) . In this implementation , the permissions management system 1204 may generate the token after accessing account information from the external user account system 1206 ( e.g. , as described herein ) and / or in response to a request received from the external user – facing system /application 1208 .”)
transmit, by the computing platform and to the data aggregator and for subsequent transmission to the third party application, the access notification based on the determined access permissions, the access notification specifying the combination of the one or more APIs and the application-specific set of one or more user accounts to which the data aggregator and the third party application are granted access. (Col. 34, ll. 16-26, The system 100 functions to provide a normalized interface ( e.g. , API service 110 ) to the one or more external user account systems ( e.g. , external user account systems 141 , 142 , and 143 ) . The system 100 enables access to a user [via a] virtualized “ image ”or digital simulation of an application instance is maintained in the application proxy system 120 and used to access the unexposed API ( e.g. , APIs 161 , 162 , and 163 ) of the external user account system.” Col. 44, ll. 58-67 “The method may additionally include verifying transaction conditions …. Transaction conditions may be used to take any suitable action . The available actions can include permitting a transaction or preventing a transaction . Additionally , the action can include sending a notification . The notification can include an email, text message , a platform message , a phone call , or any suitable notification . The action may additionally include triggering a programmatic event.”) Examiner submits that the API, as the means of access to the account information, is a “transaction condition” that may generate a notification.
As to Claim 7
Hockey and O’Kennedy discloses The computing platform of claim 1.
In addition, Hockey discloses:
wherein the one or more processors are further configured to execute the instructions to: determine, by the computing platform, token-based access permissions associated with the data transfer instructions based on a combination of the aggregator access profile and the user account authorization token; (Col. 44, 58-67“The method may additionally include verifying transaction conditions during one or more stages . Transaction conditions may be used to take any suitable action . The available actions can include permitting a transaction or preventing a transaction.” “Col. 36 ll. 30-43 … institution . The institution interface module may include a proxy sub - module that defines how the institution recognizes and / or authenticates a particular application. … some may depend on asymmetric cryptography tokens , and others may generate encrypted tokens.” …) and
transmit, by the computing platform and to the data aggregator, a token-based access notification based on the determined access permissions, the token- based access notification specifying the combination of the one or more APIs and the one or more user accounts to which the data aggregator is granted access. (“Col. 36, ll. 4-13, “Some of those properties may be automatically generated , may be provided from the institution during negotiating registration, may be properties of the application that is being simulated, and / or may include any suitable identifying and authenticating information . The properties may include a unique user identifier code , an authentication token , a MAC address e.g. , a MAC address of a user device 171 or 172 ) , or any suitable information.” Col 64, ll. 47-53, “… multiple tokens may be used in the actions described above . For example , the token stored by the trusted third party processor system 1212 may differ from the token shared with the external user - facing system/application 1208 e.g. , a different unique identifier may be shared with the external user-facing system/application 1208.)
As to Claim 8
Hockey and O’Kennedy discloses The computing platform of claim 1.
In addition, Hockey discloses:
wherein the one or more processors are further configured to execute the instructions to: modify, using hypertext transfer protocol (HTTP), the access permissions, by employing a combination of a verb and uniform resource identifier (URI). ( Fig. 8, Col 34, ll. 61-67, “The API service 110 can include various resources which act as endpoints which act as a mechanism for specifying requested information or requesting particular actions . The resources can be expressed as URI's or resource paths . The RESTful API resources can additionally be responsive to different types of HTTP methods such as GET , PUT , POST and / or DELETE .)
As to Claim 9
Hockey and O’Kennedy discloses The computing platform of claim 1.
In addition, Hockey discloses:
wherein: the user device comprises a customer device associated with a customer; (Col. 52, l. 66—Col. 53, l. 5, In one example , the external user - facing system / application 1208 may comprise an app , and / or web-based application , running on and / or rendered by the user computing device 1214 ( e.g. , a mobile device , and / or the like ) , as described above (e.g. , in reference to app 151 and / or 152 ) .)
the one or more user accounts comprise one or more customer accounts at a financial institution; and (Col. 7 , ll. 5-10, “normalized financial API request : collecting transaction information of each financial account endpoint of the normalized financial API request by using an application proxy instance associated with the financial account endpoint to collect the transaction information from a corresponding financial institution system by using the associated account credentials specified by the normalized financial API request)”
the data type access profile is obtained from the financial institution. (Fig. 1. 131, Institution interface module, Col. 36, ll. 30-43, “available in the system. The institution interface module may include a set of rules and processes of a particular institution. ... The institution interface module can additionally include institution protocol submodule , which defines a mapping between provided API 110 functionality and the form and mode of communication with the external institution…” )
As to Claim 10
Claim 10 is a method claim reciting limitations that are similar to the ones of claim 1. Therefore, claim 10 is rejected with the same rationale and motivation as applied in claim 1 above.
In addition, Hockey and O’Kennedy discloses: A processor-implemented method (Hockey Claim 1, “A computer - implemented method comprising :”)
As to Claim 11
The rejection of claim 10 is incorporated. In addition, Claim 11 is a method claim reciting limitations that are similar to the ones of claim 2. Therefore, claim 10 is rejected with the same rationale and motivation as applied in claim 2 above.
As to Claim 12
The rejection of claim 10 is incorporated. In addition, Claim 12 is a method claim reciting limitations that are similar to the ones of claim 3. Therefore, claim 10 is rejected with the same rationale and motivation as applied in claim 3 above.
As to Claim 13
The rejection of claim 10 is incorporated. In addition, Claim 13 is a method claim reciting limitations that are similar to the ones of claim 4. Therefore, claim 10 is rejected with the same rationale and motivation as applied in claim 4 above.
As to Claim 14
The rejection of claim 10 is incorporated. In addition, Claim 14 is a method claim reciting limitations that are similar to the ones of claim 5. Therefore, claim 14 is rejected with the same rationale and motivation as applied in claim 5 above.
As to Claim 16
The rejection of claim 10 is incorporated. In addition, Claim 16 is a method claim reciting limitations that are similar to the ones of claim 7. Therefore, claim 16 is rejected with the same rationale and motivation as applied in claim 7 above.
As to Claim 17
The rejection of claim 10 is incorporated. In addition, Claim 17 is a method claim reciting limitations that are similar to the ones of claim 8. Therefore, claim 17 is rejected with the same rationale and motivation as applied in claim 8 above.
As to Claim 18
Claim 18 is a computer-readable storage medium claim reciting limitations that are similar to the ones of claim 1. Therefore, claim 10 is rejected with the same rationale and motivation as applied in claim 1 above.
As to Claim 19
The rejection of claim 18 is incorporated. In addition, Claim 19 is a method claim reciting limitations that are similar to the ones of claim 5. Therefore, claim 19 is rejected with the same rationale and motivation as applied in claim 5 above.
Allowable Subject Matter
After carefully review the claims 6,15 and 20, those claims are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABU S SHOLEMAN whose telephone number is (571)270-7314. The examiner can normally be reached EST: 9am-5pm.
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, JORGE ORTIZ CRIADO can be reached at 571-272-7624. 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.
/ABU S SHOLEMAN/Primary Examiner, Art Unit 2496