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 .
Claim Objections
Claims 10, 15, 16 and 20 are objected to because of the following informality:
The claims recite “temporary data store”. Ther use of “storage” is more appropriate and consistent with the specification. A “store” has a different meaning than “storage”.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
Claims 1 – 20 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.
Claim 17: “The system of claim 16, further comprising: authenticate the user… and associate…”. This is grammatically incorrect.
Claim 19: “The system of claim 16, further comprising: before route the ongoing voice call… identify the routing target…” The phrase “before route” should be “before routing” or “before the at least one processor routes”). Combined with “further comprising,” this is problematic (similar to claim 17).
Claim 20: “The system of claim 16, further cause the at least one processor to:” — Missing words. Should read “wherein the instructions further cause the at least one processor to:”
Claims 1 – 20 recite “routing platform” and/or “target routing platform” such as 108 and 116 which may be contact centers, which may route a call. The use of “routing target” such as target agent may lead to confusion since the target is not expected to perform “routing”. That is “target routing ….” vs. “routing target” may lead to confusion.
Specification
The disclosure is objected to because of the following informalities:
Paragraph [0027]: the last 3 lines contain an apparent copy-paste error (duplication).
“…may optionally send data identified by the interaction ID 242 to the cloud service 210 (e.g., via an API), and the cloud service 210 (e.g., via an API), and the cloud service 210 may forward the data 244…”
Paragraph [0033], line 3 contains a stray closing quotation mark.
Paragraph [0052] has a grammatical error (“that excluded”). “A computer-readable storage device may be a machine-readable medium 622 that excluded transitory signals.”
Appropriate correction is required.
Claim Rejections - 35 U.S.C. § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. § 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim 1 is rejected under 35 U.S.C. § 102(a)(1) as being anticipated by Gutta et al. (US 2023/0100571 A1) (hereinafter "GUTTA").
Regarding Claim 1, GUTTA discloses a method comprising receiving, at a routing platform, an ongoing voice call. GUTTA outlines a cloud-based communication platform 108 with a receiving module 502 that handles incoming communication sessions and incoming calls (para. [0045], [0050]-[0052], [0079]-[0080]). The receiving module receives and manages incoming communication requests to establish communication sessions. Paragraphs [0040]-[0042]) demonstrate receiving an ongoing voice call at a platform.
GUTTA teaches "generating, at the routing platform, an interaction identifier associated with a user and the ongoing voice call". GUTTA teaches generating, associating, and tracking unique identifiers (e.g., session IDs and customer account identifiers) for each incoming call session (para. [0061]). GUTTA's session ID is interpreted as the claimed limitation of generating, at the routing platform, an interaction unique identifier associated with a user and the ongoing voice call because the platform dynamically generates and uses this unique tracking identifier to track, manage, and log data for the incoming communication session. See “contact identifier” and “….. may include a unique identifier associated with the customer and/or an account of the customer, a set of communication instructions for managing the incoming communication session, and/or a resource identifier identifying a location of the set of in PP [0072], [0083]-[0084].
GUTTA teaches “collecting, from a user device of the user, ongoing voice call information". GUTTA teaches capturing incoming call metadata, identifiers, and configuration parameters transmitted programmatically from the caller's client device (user device) during call initiation to route and manage the session (para. [0066]-[0067]). GUTTA's captured metadata and parameters are interpreted as the claimed limitation of collecting, from a user device of the user, ongoing voice call information because they represent caller-specific session parameters received directly from the calling client device.
GUTTA teaches "retrieving, using the ongoing voice call information, a user data record from a records data storage". GUTTA teaches using the gathered call metadata and identifiers to query a database or command registry to retrieve the appropriate account record and customer-configured communication instructions (para. [0072], [0075]-[0078]). GUTTA's retrieved communication instructions and account records are interpreted as the claimed limitation of retrieving, using the ongoing voice call information, a user data record from a records data storage because the platform retrieves account-associated communication instructions (user data records) from internal database storage using identifiers gathered from the incoming request.
GUTTA teaches "identifying a target routing platform based on the user data record and the ongoing voice call information". GUTTA teaches resolving the destination routing target by evaluating the retrieved user instructions and active call parameters to identify where the real-time stream is to be directed (para. [0084], [0088]-[0089]). GUTTA's resolved destination routing target is interpreted as the claimed limitation of identifying a target routing platform based on the user data record and the ongoing voice call information because the platform identifies the target routing destination using the user's configuration and retrieved communication instructions.
GUTTA teaches "sending a voice stream corresponding to the ongoing voice call to the target routing platform, the target routing platform including a routing target". GUTTA teaches initiating and transmitting the real-time audio stream (voice stream) to the determined network destination or recipient client device (para. [0099]-[0102]). GUTTA's transmission of the real-time audio stream is interpreted as the claimed limitation of sending a voice stream corresponding to the ongoing voice call to the target routing platform, the target routing platform including a routing target because the platform initiates and transmits a continuous voice stream to a target module or recipient device, which acts as the final endpoint or routing target.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-2, 5-6, 8, 10-12,14, 16-17 and 19 are rejected under 35 U.S.C. § 103 as being unpatentable over Muir et al. (US 6,661,882 B1) (“Muir”) in view of Pickford (US 2014/0226807 A1) (“Pickford”).
Regarding Claim 1, Muir discloses a method (Muir, col. 1, ll. 14–20) comprising:
receiving, at a routing platform, an ongoing voice call (Muir teaches receiving a call at a network integrated voice response (NIVR) platform: “when a telephone call from a consumer to an organization, such as a financial institution, is transferred from an integrated voice response (IVR) agent” (Muir, col. 5, ll. 13-24 and col. 6, ll. 8–23);
generating, at the routing platform, an interaction identifier associated with a user and the ongoing voice call (Muir teaches generating a per-call Session ID: “provides each call that comes into the integrated voice response (IVR) system with a session identification (ID) that is held onto by the host” (Muir, col. 2, ll. 49–52); “The Session ID is established by the NIVR platform at the start of each successful ANI or Account Match host transaction” (Muir, col. 30, II 16-38, col. 31, II 11-16.
collecting, from a user device of the user, ongoing voice call information (Muir teaches the NIVR collecting caller-entered information: “a call enters the NIVR, the caller enters his/her account number, listens to his/her account information” (Muir, col. 8, l. 66 – col. 9, l. 2);
retrieving, using the ongoing voice call information, a user data record from a records data storage (Muir teaches an account look-up: “performs a table look-up to find the associated account number. The host then provides the account information to the agent” (Muir, col. 9, ll. 11–15);
identifying a target routing platform based on the user data record and the ongoing voice call information (Muir teaches routing decisions based on caller type and call information: “The network router reads the particular field and makes a routing decision based on what type of customer the caller is and what type of agent is available to service that type of customer” (Muir, col. 5, ll. 66– col. 6, II. 23); and
sending a voice stream corresponding to the ongoing voice call to the target routing platform, the target routing platform including a routing target (Muir teaches routing the call to the agent with associated data: “The host matches the Session ID for both CICS region and temp storage location and sends the associated information to the agents CRT” (Muir, col. 26, II 8-12).
Muir does not expressly disclose identifying a target routing platform …. and sending ….. to the target routing platform.
On one hand, the claim does not recite that the “target routing platform” is different from the “routing platform”, and the claimed “target routing platform” may read on the network integrated voice response (NIVR) platform in Muir.
On the other hand, if the target routing platform is an identified routing platform among a plurality of routing platforms (which is not clearly recited), then Pickford teaches identifying a target routing platform among multiple call centers based on caller information and the reason for the call: “identifying an agent skill group based on the likely reason for the call, and providing an available agent with access to the caller’s account information” (Pickford, Abstract); “thereby allowing multiple call centers (routing platforms) located in geographically different areas to operate as a seamless virtual call center” (Pickford, Abstract). Pickford further teaches routing to an available agent with the account information presented: “the caller is routed to an available agent, and the caller’s customer account in the system is accessed and presented to the agent’s computer, along with a query script based on the pre-determined likely reason for the call 2014” (Pickford, ¶[0042]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Muir to identify a target routing platform among multiple routing platforms as taught by Pickford, in order to route callers to the best available agent across geographically distributed centers while preserving call context. The motivation to do so is expressly provided by Pickford: “to allow multiple ACDs, particularly when located in geographically different areas of the world, to operate as a single seamless virtual call center” (Pickford, ¶[0008]). This combination applies a known technique (Muir’s session-identifier-based coordination of voice and caller data) to a known system (Pickford’s multi-center routing) to yield predictable results. See KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398 (2007).
Regarding Claim 10, Muir discloses a method comprising:
receiving, at a routing platform, a voice stream including an interaction identifier related to an ongoing voice call and a user (Muir teaches that a transferred call carries the Session ID in the ANI field: “When a ‘host matched’ call is transferred, the Session ID is placed in the last five digits of the ANI field. The first digit of the Session ID identifies the NIVR node that the call originated from and is used by the receiving CICS region… The last four digits contain the temp storage address of the actual account information” (Muir, col. 25, II. 60- col. 26, II. 7);
sending, to a temporary data store, a data request for a temporary data record, the data request including the interaction identifier from the voice stream (Muir teaches using the Session ID to access temporary storage: “inside those ten digits is a five digit field that tells the system where to go in its temporary storage to get the information about the original call in the IVR in order to pop to the agent’s screen” (Muir, col. 3, ll. 6–10); “The host matches the Session ID for both CICS region and temp storage location” (Muir, col. 26, II. 9-12);
receiving, from the temporary data store, the temporary data record related to the ongoing voice call (Muir teaches retrieval of the stored call information: “The host retrieves the call information and sends it to the CTI server” (Muir, col. 28, II 24-29);
determining a routing target based on the temporary data record (Muir teaches determining the agent skill/split from the call information: “The call routing script uses the Call Type and Info to determine the agent skill/availability best fitted to handle the call. If the best skill is unavailable, the scripting will determine the next best skill for call routing” (Muir, FIG. 2 description included in Fig. 2); and
routing the ongoing voice call and the temporary data record to the routing target (Muir teaches routing the call to the agent with the associated data delivered as a screen pop: “The host matches the Session ID… and sends the associated information to the agents CRT” (Muir, col. 26, II 7-11).
Similar to claim 1 above, Muir does not expressly disclose determining a “routing target” [which is or within another routing platform].
On one hand, the claim does not recite that the “routing target” is not within the “routing platform”, and thus it may read on a “routing target” (agent) within the routing platform (NIVR platform) of Muir.
On the other hand, if the routing target (agent) is within another routing platform (which is not claimed), then Pickford teaches identifying a “routing target” within multiple call centers based on caller information and the reason for the call: “identifying an agent skill group based on the likely reason for the call, and providing an available agent with access to the caller’s account information” (Pickford, Abstract); “thereby allowing multiple call centers (routing platforms) located in geographically different areas to operate as a seamless virtual call center” (Pickford, Abstract). Pickford further teaches routing to an available agent with the account information presented: “the caller is routed to an available agent, and the caller’s customer account in the system is accessed and presented to the agent’s computer, along with a query script based on the pre-determined likely reason for the call 2014” (Pickford, ¶[0042]).
Pickford teaches routing to an available agent selected based on caller data and the reason for the call: “an appropriate group of agents 2010 with relevant skills for the likely reason for the call is identified and the caller is routed to that group” (Pickford, ¶[0042]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Muir and Pickford for the reasons and with the motivation set forth above with respect to Claim 1. See KSR, 550 U.S. 398.
Regarding Claim 16, Muir in view of Pickford discloses a system comprising:
at least one processor; and memory including instructions that, when executed by the at least one processor, cause the at least one processor to: (Muir is implemented on host/mainframe computers and CTI servers executing software; Pickford expressly teaches a processor and memory executing instructions: “Computer system 200 includes one or more processors, such as processor 204” (Pickford, ¶[0080]); “Computer programs… are stored in main memory 208 and/or secondary memory 210… when executed, enable the computer system 200 to perform the features of the present invention” (Pickford, ¶[0084]));
receive, at a routing platform, a voice stream including an interaction identifier related to a user and an ongoing voice call (Muir, as set forth above with respect to Claim 10);
send a data request for a data record to a temporary data store, the data request including the interaction identifier from the voice stream (Muir, as set forth above with respect to Claim 10);
receive the data record from the temporary data store, the data record related to the user and the ongoing voice call (Muir, as set forth above with respect to Claim 10); and
route the ongoing voice call and the data record to a routing target (Muir, Pickford, as set forth above with respect to Claim 10).
Claim 16 is a system reciting limitations commensurate in scope with method Claim 10, further reciting a processor and memory. It is therefore rejected on the same grounds and for the same reasons set forth above with respect to Claims 10 and 1, and on the basis of Pickford’s express disclosure of a processor/memory computing system (Pickford, ¶¶[0080], [0084]).
Claims 2, 11, and 17 — Authenticating the user based on the record
Claim 2 recites “before retrieving the user data record from the records data storage, authenticating the user based on the ongoing voice call information.”
Claim 11 recites “after receiving the temporary data record, authenticating the user based on one or more parameters of the temporary data record; and associating, in response to authenticating the user, the temporary data record with the ongoing voice call.”
Claim 17 recites the same substance as Claim 11 in system form.
Muir teaches authenticating the caller based on collected call information prior to and in connection with accessing account records: “Customers are identified in the application by entering a valid account number and PIN” (Muir, col. 22, II. 42-47— “Cards Products NIVR application”; “This activity is allowed after the caller successfully enters their 14 or 16 digit CHIN and their 4-6 digit Telephone Personal Identification Code (TIC)” (Muir, col.26, II. 37-39). Muir further teaches associating the retrieved record with the call via the Session ID: “Session ID is a five-digit field that is used to match a NIVR transferred call with associated account information” (Muir, col. 25, II 6-62).
Furthermore, it is well-known in the art to authenticate the user as taught by Muir in order to verify the caller’s identity before providing access to sensitive account information, a well-known and expected practice in financial call centers. See KSR, 550 U.S. 398.
Claim 5 — Identifying a user account number and a user intent
Claim 5 recites “identifying, using the ongoing voice call information, the user, wherein identifying the user includes identifying a user account number and a user intent.”
Muir teaches identifying the caller by account number (Muir, col. 8, II 66 –Co. 9m II 14), “the caller enters his/her account number” and determining caller intent/reason for the call. Pickford teaches determining the reason for the call: “determining the likely reason for the call” (Pickford, Abstract); “an evaluation is made as to the likely reason or reasons for the call 2008” (Pickford, ¶[0040]).
Knowing the account number (Muir) and the user intent/reason for the call (Pickford) will help in routing the call to an appropriately skilled agent.
Claim 6 — Sending status requests to a plurality of routing platforms
Claim 6 recites “sending status requests for routing target statuses to a plurality of routing platforms; and receiving a plurality of routing target statuses… wherein identifying the target routing platform is further based on the plurality of routing target statuses.”
Pickford teaches determining the availability status of agents across multiple centers (multiple routing platforms) and using real-time status to make routing decisions: “determining the availability status of each of the agents and each available agent’s skill sets” (Pickford, ¶[0014]); “Real time statistics allow determination of how many agents should be available and what skill set those agents should have” (Pickford, Abstract); “This information is then utilized in conjunction with information received about a caller… to allow the caller to be routed to the most appropriate available agent” (Pickford, ¶[0016]).
Claims 8 and 19 — Sending the user data record / identifying the routing target from the record
Claim 8 recites “sending the user data record of the user to the target routing platform.” Muir teaches sending the associated account/call data to the destination for delivery to the agent: “The host matches the Session ID… and sends the associated information to the agents CRT” (Muir, col. 26, II 8-12); Pickford, ¶[0042] (account presented to the agent’s computer).
Claim 19 recites before route [routing] the ongoing voice call and the data record to the routing target, identify [identifying] the routing target based on the data record.” Muir teaches determining the agent/routing target from the retrieved call information (Muir, FIG. 2 description, “uses the Call Type and Info to determine the agent skill/availability”); Pickford, ¶[0042].
Claim 12 — Authenticating without using the interaction identifier
Claim 12 recites “wherein authenticating the user includes authenticating the user without using the interaction identifier.” Muir teaches authenticating the caller using account number and PIN (Muir, NIVR application description, as cited above with respect to Claim 11) — credentials distinct from the Session ID, which is used for record matching rather than authentication. Muir thus teaches authentication performed on parameters other than the interaction identifier. Many authentication methods are well-known and widely used.
Claim 14 — Sending a target status to a second routing platform before receiving the voice stream
Claim 14 recites “before receiving the voice stream from a second routing platform, sending a target status to the second routing platform.”
Pickford teaches that the availability status of agents at each platform is determined and made available to support cross-platform routing decisions: “determining the availability status of each of the agents and each available agent’s skill sets” (Pickford, ¶[0014]); “This information is then utilized in conjunction with information received about a caller… to allow the caller to be routed to the most appropriate available agent” (Pickford, ¶[0016]). In the seamless virtual call center of Pickford, in which “multiple call centers located in geographically different areas… operate as a seamless virtual call center” (Pickford, Abstract), each center provides its status for use in routing calls to it.
Claims 3, 4, 7, 13 and 18 are rejected under 35 U.S.C. § 103 as being unpatentable over Muir in view of Pickford as applied to Claims 1, 8, 10, and 16 respectively, and further in view of Gutta et al. (US 2023/0100571 A1) (“Gutta”).
Claim 3 recites “wherein collecting the ongoing voice call information includes collecting information using a chatbot.”
As discussed above, Muir teaches collecting call information via the automated NIVR/IVR (Muir, col. 8–9, caller enters account number). Muir does not expressly use the term “chatbot.”
The chatbots are well-known in the art and have been widely used for many years. Gutta teaches automated, conversational collection and response functionality applied to communications, including intent determination and generated responses: “implement an intent determination feature in which the intent of the communication is determined, and a response communication or recommendation is generated” (Gutta, ¶[0012] and [0055]_.
It would have been obvious to one of the ordinary skill in the art before the effective filing date to collect the call information using the well-known chatbot which is also suggested by Gutta’s automated intent/response functionality, in place of or in addition to Muir’s IVR, in order to automate caller information collection using known conversational-automation techniques yielding predictable results. See KSR, 550 U.S. 398.
Claims 4, 13, and 18 recite that “the routing target includes at least one of an artificial intelligence agent, a human agent, or a voicemail.”
Muir and Pickford teach a human agent as the routing target (Muir, col. 26, II 8-12 “sends the associated information to the agents CRT”; Pickford, ¶[0042], “routed to an available agent”). This alone satisfies the “at least one of” recitation.
To the extent an artificial intelligence agent (as an option), Gutta teaches routing communications to services implementing artificial-intelligence functionality: “a customer may use the streamed media to implement an intent determination feature in which the intent of the communication is determined, and a response communication or recommendation is generated” (Gutta, ¶[0012 and [0055]); “use the media to train a machine learning or artificial intelligence model” (Gutta, ¶[0070]).
It would have been obvious to one of ordinary skill in the art before the effective filing date to provide an artificial-intelligence agent as a routing target, as taught by Gutta, in combination with the human-agent routing of Muir and Pickford, in order to automate handling of communications and reduce reliance on human agents. See KSR, 550 U.S. 398. Alternatively, the claim is met by Muir and Pickford alone under the “at least one of” language via the disclosed human agent.
Claim 7 recites “wherein receiving, at the routing platform, the ongoing voice call is via a first public carrier, and sending the voice stream corresponding to the ongoing voice call to the target routing platform is via a second public carrier.”
Muir teaches receiving calls via a public carrier network (Muir, col. 4, II 23-32, — “Upon the caller… initiating the call via a publicly switched telephone network (‘PSTN’) or another network”). Muir further teaches out-dialing transferred calls over carrier networks via different (e.g., 800) numbers: “The system also involves out dialing different 800 numbers for different reasons on the back end of the process” (Muir, col. 6, II 50-61). To the extent transmission via a distinct second public carrier is required, Gutta teaches communications received from and transmitted to distinct network destinations over carrier/data networks (Gutta, ¶¶[0071], [0116], receiving via a telecommunication carrier and public switched telephone network; transmitting to network destinations).
It would have been obvious to one of ordinary skill in the art to receive the call via a first public carrier and transmit the voice stream via a second public carrier, as suggested by Muir’s back-end out-dialing over carrier networks and Gutta’s carrier-based transport, in order to route the call to a destination platform served by a different carrier. See KSR, 550 U.S. 398.
Allowable Subject Matter
Claims 9, 15 and 20 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
The closest prior art (Muir, US 6,661,882; Pickford, US 2014/0226807; Gutta, US 2023/0100571) teaches session-identifier-keyed temporary storage and multi-platform call routing, but does not teach or fairly suggest:
Claim 9: before sending the voice stream to the target routing platform, receiving a confirmation that a data record identified by the interaction identifier was created at a temporary data storage.
Claims 15 and 20: sending, to the temporary data store, a request to delete the temporary data record, and receiving a confirmation that the record was deleted.
No reference of record, alone or in combination, teaches these limitations when taken in combination with the limitations of the intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AHMAD F. MATAR whose telephone number is (571)272-7488. The examiner can normally be reached M-F 9 - 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.
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.
/AHMAD F. MATAR/ Supervisory Patent Examiner, Art Unit 2693
Prosecution Insights