Detailed Action
Claims 1-20 are pending
Claims 1-20 are rejected.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-11 are rejected under 35 U.S.C. 103 as being unpatnetable over Huang (Pub. No.: US 2017/0187768 A1) in view of Kitamura (Pub. No.: US 2013/0212127 A1) and David Schinazi (Apple and IPv6 - Happy Eyeballs published 09 July 2015 Schinazi hereinafter).
As per claim 1, Huang discloses: a method of serving content comprising:- obtaining a resource (Huang; par. [0010], wherein “the user device may obtain streaming media content from a CDN and/or a host device that is located nearest to the user device”) in accordance with a manifest file (Huang; par. [0008], “For example, the user device may receive (e.g., from a content provider device) a manifest file that includes multiple resource identifiers (e.g., uniform resource identifiers (URIs), uniform resource locators (URLs), or the like) that may allow the user device to access the streaming media content. The user device may request a segment of the streaming media content using a request (e.g., a hypertext transfer protocol (HTTP) request (e.g., an HTTP GET request), or the like)”);- maintaining a first address record associated with serving the resource, the first address record associated with a first protocol for a first device capable of serving the resource (Huang; Fig 1D, for example, the first address record serving the resource can be ‘http://example.file9/CDN2 – 123.45.67.8’ which is associated with a first protocol “http” for a first device having the IP address 123.45.67.8); - maintaining a second address record associated with serving the resource, the second address record associated with a second protocol, (Huang; Fig 1D, for example, the second address record serving the resource can be ‘http://example.file12/CDN2 – 234.56.78.9’ which is associated with a second protocol “http” for a second device having the IP address 234.56.78.9); and - in response to at least one resolution request for the resource, providing the first address record and the second address record (Huang; Fig 1D, par. [0020], wherein “For example, assume that a domain name server resolves a host name in the resource identifiers to a network address (e.g., an interne protocol (IP) address) associated with a particular host device (e.g., Host Device 1)”; par. [0025], wherein “the domain name server may resolve host names to a network address associated with Host Device 2 (e.g., “234.56.78.9”)”);- requesting each one of the associated resources in an order specified in the manifest file (Huang; Fig 1C, par. [0020, 0022, 0025], wherein “the user device may request streaming content using resource identifiers associated with CDN 2. For example, assume that a domain name server resolves a host name in the resource identifiers to a network address (e.g., an interne protocol (IP) address) associated with a particular host device (e.g., Host Device 1). Host Device 1 may receive the request and may provide the user device with the streaming media content”, “For example, assume that the streaming optimization server determines that a score associated with Host Device 2 is higher than a score associated with Host Device 1 (e.g., indicating that Host Device 2 is capable of delivering the streaming media content at a lower latency, a reduced packet loss rate, etc. than Host Device 1)”, “the user device may request streaming media content. Based on the domain name server updating the data structure, the domain name server may resolve host names to a network address associated with Host Device 2 (e.g., “234.56.78.9”). In this way, Host Device 2 may provide the streaming media content to the user device”; Thus, initially, the resource was requested using the resource identifier of Host Device 1 and then the resource was requested using the resource identifier of Host Device 2.); and- identifying the device that most effectively delivers the resource (Huang; par. [0022-0023], wherein “the streaming optimization server may determine scores associated with the host devices. For example, the streaming optimization server may determine scores associated with the host devices in a similar manner as described above in connection with determining scores for CDNs. For example, assume that the streaming optimization server determines that a score associated with Host Device 2 is higher than a score associated with Host Device 1 (e.g., indicating that Host Device 2 is capable of delivering the streaming media content at a lower latency, a reduced packet loss rate, etc. than Host Device 1)”);- evaluating network performance to the first device and to the second device (Huang; par. [0022-0023], wherein “the streaming optimization server may determine scores associated with the host devices. For example, the streaming optimization server may determine scores associated with the host devices in a similar manner as described above in connection with determining scores for CDNs. For example, assume that the streaming optimization server determines that a score associated with Host Device 2 is higher than a score associated with Host Device 1 (e.g., indicating that Host Device 2 is capable of delivering the streaming media content at a lower latency, a reduced packet loss rate, etc. than Host Device 1)”). Huang does not explicitly disclose a dual protocol network stack environment, the second protocol is different from the first protocol and serving the resource using a default protocol when the network performance data to the first device and to the second device are within a predetermined margin. However, Kitamura discloses a dual protocol network stack environment and that the second protocol is different from the first protocol (Kitamura; Fig 1, 10, paragraph 0063, wherein Fig 1 for example, shows a first address record associated with a first protocol (IPv4) and a second address record associated with a second protocol (IPv6)).
Therefore, it would have been obvious to one ordinary skill in the art before the effective filing date of the invention to combine Huang with Kitamura so that two distinct protocols are used as claimed because this would have provided away to support serving content from devices running on different protocols (IPv4, IPv6) which increases the efficiency and performance of the system by providing a name resolution system capable of performing name resolution on both IPv4 and IPv6 by querying a host name once even in the mixed communication environment of IPv4 and IPv6 (see Kitamura paragraph 0002, 0025).Huang and Kitamura do not explicitly disclose serving the resource using a default protocol when the network performance data to the first device and to the second device are within a predetermined margin. However, Schinazi discloses serving the resource using a default protocol when the network performance data to the first device and to the second device are within a predetermined margin (Schinazi; page 1, wherein “The updated implementation performs the following:
- Query the DNS resolver for A and AAAA.
If the DNS records are not in the cache, the requests are sent back to back on the wire, AAAA first.
- If the first reply we get is AAAA, we send out the v6 SYN immediately
- If the first reply we get is A and we're expecting a AAAA, we start a 25ms timer
- If the timer fires, we send out the v4 SYN
- If we get the AAAA during that 25ms window, we move on to address selection
- When we have a list of IP addresses (either from the DNS cache or by receiving them close together with v4 before v6),
we perform our own address selection algorithm to sort them. This algorithm uses historical RTT data to prefer addresses that have lower latency - but has a 25ms leeway: if the historical RTT of two compared address are within 25ms of each
other, we use RFC3484 to pick the best one.
- Once the list is sorted, we send out the SYN for the first address and start timers based on average and variance of the historical TCP RTT. Roughly speaking, we start the second address around the same time we send out a SYN retransmission for the first address.
- The first address to reply with a SYN-ACK wins the race, we then cancel the other TCP connection attempts.”).
Therefore, it would have been obvious to one ordinary skill in the art before the effective filing date of the invention to combine Huang, Kitamura with Schinazi to achieve the claimed limitation because this would have provided away to apply Happy Eyeballs algorithm to select the best protocol to server the requested resource in a way that improve the performance of the system.
As per claim 2, claim 1 is incorporated and Kitamura further discloses wherein the first protocol is Internet Protocol version 4 (IPv4) and the second protocol is Internet Protocol version 6 (IPv6) (Kitamura; Fig 1, 10, paragraph 0063, wherein Fig 1 for example, shows a first address record associated with a first protocol (IPv4) and a second address record associated with a second protocol (IPv6)).
As per claim 3, claim 1 is incorporated and Kitamura further discloses wherein the first address record is an A record and the second address record is an AAAA record (Kitamura; Fig 1, 10, paragraph 0063, wherein Fig 1 for example, shows an A address record associated with a first protocol (IPv4) and an AAAA address record associated with a second protocol (IPv6)).
As per claim 4, claim 1 is incorporated and Kitamura further discloses wherein the first address record and the second address record is associated with a first content delivery server and a second content delivery server, respectively, of a content delivery network (Huang, Fig 1A-E, paragraph 0014, wherein “For example, the network processing unit may monitor streaming media traffic (e.g., associated with multiple content delivery networks and multiple user devices) and may measure performance metrics associated with the multiple content delivery networks (e.g., latency values, jitter values, packet loss values, bandwidth values, throughput values, etc.). The streaming optimization server may receive information identifying the performance metrics and may store the information in a performance table (e.g., a data structure). For example, CDN 1 and CDN 2 may be providing streaming media content”).
As per claim 5, claim 1 is incorporated and Kitamura further discloses wherein the first address record and the second address record are provided to a client device (Kitamura; Fig 1, 10, par. [0054-0056], wherein as shown in Fig 1 for example, the client sends a DNS request to the DNS server and the DNS server provides to the client the first address record and the second address record). Schinazi disclose that the client device configured to execute a performance test in response to receiving the first address record and the second address record to assess the performance of obtaining the resource from the first device using the first address record and the performance of obtaining the resource from the second device using the second address record (Schinazi; page 1, wherein “The updated implementation performs the following:
- Query the DNS resolver for A and AAAA.
If the DNS records are not in the cache, the requests are sent back to back on the wire, AAAA first.
- If the first reply we get is AAAA, we send out the v6 SYN immediately
- If the first reply we get is A and we're expecting a AAAA, we start a 25ms timer
- If the timer fires, we send out the v4 SYN
- If we get the AAAA during that 25ms window, we move on to address selection
- When we have a list of IP addresses (either from the DNS cache or by receiving them close together with v4 before v6),
we perform our own address selection algorithm to sort them. This algorithm uses historical RTT data to prefer addresses that have lower latency - but has a 25ms leeway: if the historical RTT of two compared address are within 25ms of each
other, we use RFC3484 to pick the best one.
- Once the list is sorted, we send out the SYN for the first address and start timers based on average and variance of the historical TCP RTT. Roughly speaking, we start the second address around the same time we send out a SYN retransmission for the first address.
- The first address to reply with a SYN-ACK wins the race, we then cancel the other TCP connection attempts.”)
As per claim 6, claim 5 is incorporated and Schinazi further discloses the performance test includes executing a Happy Eyeballs function (Schinazi; page 1, wherein “Based on our testing, this makes our Happy Eyeballs implementation go from roughly 50/50 IPv4/IPv6 in iOS 8 and Yosemite
to ~99% IPv6 in iOS 9 and El Capitan betas”).
As per claim 7, claim 1 is incorporated and Huang and Kitamura do not explicitly disclose that at least one of the first address record and the second address record correspond to a virtual internet protocol address. However, using virtual IP addresses is well known in the art.
Therefore, it would have been obvious to one ordinary skill in the art before the effective filing date of the invention to modify Huang and Kitamura so that the first and/or the second IP address is virtual as claimed because this would have provided a way to get the benefits of virtual IP addresses such as improve mobility.
Claims 8-11 are rejected under the same rationale as claims 1-7. In addition, Kitamura discloses a directory server (Kitamura; Fig 1, 10 (DNS server))
Claims 12-13 are rejected under 35 U.S.C. 103 as being unpatnetable over Huang (Pub. No.: US 2017/0187768 A1) in view of Kitamura (Pub. No.: US 2013/0212127 A1), David Schinazi (Apple and IPv6 - Happy Eyeballs published 09 July 2015 Schinazi hereinafter) and Lyon (Pub. No.: US 2013/0103853 A1).
As per claim 12, claim 8 is incorporated and Huang, Kitamura and Schinazi do not explicitly disclose wherein the directory server is configured to identify the first address and the second address based, at least in part, on one or more characteristics of a device associated with the resolution request. However, Lyon discloses the directory server is configured to identify the first address and the second address based, at least in part, on one or more characteristics of a device associated with the resolution request (Lyon, Fig 3, paragraph 0019, wherein traffic manager 302 takes into consideration the communication format that gives a client the best expected performance when making a redirection decision. In some cases, for example, better performance may be expected by redirecting a client to a server connected to a network to which the client is natively connected. For instance, better performance may be expected by redirecting a native IPv4 client 304(a) to a native IPv4 server 306(a) and similarly a native IPv6 client 304(b) to a native IPv6 server 306(b) to avoid the performance degradations inherent in tunneling communications over otherwise incompatible networks. In some embodiments, traffic manager 302 is configured to determine whether a communication received from a client has been tunneled using a tunneling service. A tunneled communication may be identified, for example, by comparing a source IP address of the communication with a list or database of known IP addresses associated with tunneling services).
Therefore, it would have been obvious to one ordinary skill in the art before the effective filing date of the invention to combine Lyon with Huang and Kitamura to achieve the claimed limitation because this would have provided a way to improve the performance of the system by giving a client the best expected performance when making a redirection decision (see Lyon, paragraph 0019).
As per claim 13, claim 12 is incorporated and Kitamura in view of Lyon further discloses the device associated with the resolution request is one of a client device from which the resolution request originates and an intermediate device through which the resolution request is communicated to the directory server (Kitamura; Fig 1,3, 10); and the one or more characteristics include at least one of a location of the device associated with the resolution request, information pertaining to an entity deploying the device associated with the resolution request, and information pertaining to other devices in communication with the device associated with the resolution request (Lyon, Fig 3, paragraph 0019, wherein traffic manager 302 takes into consideration the communication format that gives a client the best expected performance when making a redirection decision. In some cases, for example, better performance may be expected by redirecting a client to a server connected to a network to which the client is natively connected. For instance, better performance may be expected by redirecting a native IPv4 client 304(a) to a native IPv4 server 306(a) and similarly a native IPv6 client 304(b) to a native IPv6 server 306(b) to avoid the performance degradations inherent in tunneling communications over otherwise incompatible networks. In some embodiments, traffic manager 302 is configured to determine whether a communication received from a client has been tunneled using a tunneling service. A tunneled communication may be identified, for example, by comparing a source IP address of the communication with a list or database of known IP addresses associated with tunneling services).
Claims 14-16 and 18-20 are rejected under 35 U.S.C. 103 as being unpatnetable over Huang (Pub. No.: US 2017/0187768 A1) in view of David Schinazi (Apple and IPv6 - Happy Eyeballs published 09 July 2015 Schinazi hereinafter).
As per claim 14, Huang discloses: a system for providing content comprising:- a name server and corresponding content delivery network , wherein the content delivery network comprises at least a first content delivery network device with a first address and a second content delivery network device with a second address (Huang; Fig 2, par. [0029, 0037], wherein “As shown in FIG. 2, environment 200 may include one or more user devices 205 (hereinafter referred to collectively as “user devices 205,” and individually as “user device 205”), a base station 210, a network processing unit (NPU) 215, a streaming optimization server 220, a content provider device 225, one or more CDN servers 230-1 through 230-N (N≧1) (hereinafter referred to collectively as “CDN servers 230,” and individually as “CDN server 230”), one or more domain name servers (DNS) 235-1 through 230-M (M≧1) (hereinafter referred to collectively as “DNSs 235,” and individually as “DNS 235”), one or more host devices 240-1 through 240-P (P≧1) (hereinafter referred to collectively as “host devices 240,” and individually as “host device 240”), a network 245, and one or more content delivery networks (CDNs) 250-1 through 250-Q (Q≧1) (hereinafter referred to collectively as “CDNs 250,” and individually as “CDN 250”)”, “DNS 235 may receive information that identifies a domain name, and may provide information that identifies a network address mapped to the domain name (e.g., a network address of host device 240)”; For example, DNS 235-1 can be the name server corresponding to content delivery network CDN 250-1 which comprises multiple CDN Server 230-1 and Host Device 240-1 as first and second content delivery network devices each having a first and second addresses respectively); and- a client device (Huang; Fig 2 item 205, par. [0029-0030], wherein “As shown in FIG. 2, environment 200 may include one or more user devices 205 (hereinafter referred to collectively as “user devices 205,” and individually as “user device 205”)”, “User device 205 may include one or more devices capable of receiving, generating, storing, processing, and/or providing information associated with streaming media content. For example, user device 205 may include a communication and computing device, such as a mobile phone (e.g., a smart phone, a radiotelephone, etc.), a laptop computer, a tablet computer, a handheld computer, a gaming device, a wearable communication device (e.g., a smart wristwatch, a pair of smart eyeglasses, etc.), a set-top box, or a similar type of device”), wherein the client device obtains performance data corresponding to the first address and the second address (Huang; Fig 4 step 410, par. [0050-0051], wherein “FIG. 4 is a flow chart of an example process 400 for determining scores associated with content delivery networks. In some implementations, one or more process blocks of FIG. 4 may be performed by streaming optimization server 220. In some implementations, one or more process blocks of FIG. 4 may be performed by another device or a group of devices separate from or including streaming optimization server 220, such as user device 205”, “As shown in FIG. 4, process 400 may include receiving information, associated with streaming media traffic, associated with content delivery networks (block 410). For example, streaming optimization server 220 may receive information, associated with streaming media traffic, associated with CDNs 250”.par. [0058], wherein “streaming optimization server 220 may receive information associated with one or more performance metrics associated with each CDN 250. For example, a performance metric may be measured by latency, jitter, bandwidth, throughput, packet loss, bit error rate, a quantity of cache hits, a quantity of cache misses, load, or the like. In some implementations, the one or more performance metrics may be associated with streaming media traffic associated with content provider device 225 (e.g., may be associated with a particular stream)”).Huang and Kitamura do not explicitly disclose wherein the client device default to a particular protocol when the performance data are within a predetermined margin of round-trip time. However, Schinazi discloses wherein the client device default to a particular protocol when the performance data are within a predetermined margin of round-trip time (Schinazi; page 1, wherein “The updated implementation performs the following:
- Query the DNS resolver for A and AAAA.
If the DNS records are not in the cache, the requests are sent back to back on the wire, AAAA first.
- If the first reply we get is AAAA, we send out the v6 SYN immediately
- If the first reply we get is A and we're expecting a AAAA, we start a 25ms timer
- If the timer fires, we send out the v4 SYN
- If we get the AAAA during that 25ms window, we move on to address selection
- When we have a list of IP addresses (either from the DNS cache or by receiving them close together with v4 before v6),
we perform our own address selection algorithm to sort them. This algorithm uses historical RTT data to prefer addresses that have lower latency - but has a 25ms leeway: if the historical RTT of two compared address are within 25ms of each
other, we use RFC3484 to pick the best one.
- Once the list is sorted, we send out the SYN for the first address and start timers based on average and variance of the historical TCP RTT. Roughly speaking, we start the second address around the same time we send out a SYN retransmission for the first address.
- The first address to reply with a SYN-ACK wins the race, we then cancel the other TCP connection attempts.”).
Therefore, it would have been obvious to one ordinary skill in the art before the effective filing date of the invention to combine Huang with Schinazi to achieve the claimed limitation because this would have provided away to apply Happy Eyeballs algorithm to select the best protocol to server the requested resource in a way that improve the performance of the system.
As per claim 15, claim 14 is incorporated and Huang further discloses wherein obtaining the performance data comprises a pinging operation (Huang; paragraph 0058, wherein “streaming optimization server 220 may receive information associated with one or more performance metrics associated with each CDN 250. For example, a performance metric may be measured by latency, jitter, bandwidth, throughput, packet loss, bit error rate, a quantity of cache hits, a quantity of cache misses, load, or the like. In some implementations, the one or more performance metrics may be associated with streaming media traffic associated with content provider device 225 (e.g., may be associated with a particular stream)”; wherein the latency and/or packet loss information can be the data comprises a pinging operation).
As per claim 16, claim 14 is incorporated and Huang further discloses wherein obtaining the performance data comprises a pinging operation with multiple requests (Huang; paragraph 0058, wherein “streaming optimization server 220 may receive information associated with one or more performance metrics associated with each CDN 250. For example, a performance metric may be measured by latency, jitter, bandwidth, throughput, packet loss, bit error rate, a quantity of cache hits, a quantity of cache misses, load, or the like. In some implementations, the one or more performance metrics may be associated with streaming media traffic associated with content provider device 225 (e.g., may be associated with a particular stream)”; wherein the latency and/or packet loss information can be the data comprises a pinging operation for multiple requests (performance metrics associated with each CDN 250)).
As per claim 18, claim 14 is incorporated and Huang further discloses wherein obtaining the performance data comprises an exchange of connection requests and responses (Huang; paragraph 0058, wherein “streaming optimization server 220 may receive information associated with one or more performance metrics associated with each CDN 250. For example, a performance metric may be measured by latency, jitter, bandwidth, throughput, packet loss, bit error rate, a quantity of cache hits, a quantity of cache misses, load, or the like. In some implementations, the one or more performance metrics may be associated with streaming media traffic associated with content provider device 225 (e.g., may be associated with a particular stream)”; wherein the latency and/or packet loss information can be the data comprises a pinging operation for multiple requests (performance metrics associated with each CDN 250)).
As per claim 19, claim 18 is incorporated and Huang further discloses wherein the connection requests are sent to the first content delivery network device and the second content delivery network device simultaneously (Huang; paragraph 0050, 0058, wherein “streaming optimization server 220 may receive information associated with one or more performance metrics associated with each CDN 250. For example, a performance metric may be measured by latency, jitter, bandwidth, throughput, packet loss, bit error rate, a quantity of cache hits, a quantity of cache misses, load, or the like. In some implementations, the one or more performance metrics may be associated with streaming media traffic associated with content provider device 225 (e.g., may be associated with a particular stream)”; wherein the latency and/or packet loss information can be the data comprises a pinging operation for multiple requests (performance metrics associated with each CDN 250)).
As per claim 20, claim 18 is incorporated and Huang further discloses wherein the connection requests are sent to the first content delivery network device first, wherein the first content delivery network device utilizes a preferred protocol (Huang; paragraph 0018, 0031, wherein “In some implementations, the message may cause the user device to request the streaming media content from another CDN based on the other CDN including a particular score. For example, assume that CDN 2 includes a score of “A,” whereas CDN 1 includes a score of “B” (e.g., indicating that CDN 2 may provide the streaming media content at a reduced latency, at a reduced packet loss rate, etc. as compared to CDN 1); “User device 205 may request streaming media content by requesting segments of the media stream (e.g., using HyperText Transfer Protocol (HTTP) Live Streaming (HLS), Dynamic Adaptive Streaming over HTTP (DASH), HTTP Dynamic Streaming, HTTP Adaptive Streaming, Microsoft Smooth Streaming, or the like)”).
Claim 17 is rejected under 35 U.S.C. 103 as being unpatnetable over Huang (Pub. No.: US 2017/0187768 A1) in view of David Schinazi (Apple and IPv6 - Happy Eyeballs published 09 July 2015 Schinazi hereinafter) and LI et al (Pub. No.: US 2013/0013730 A1).
As per claim 17, claim 14 is incorporated and Huang does not explicitly disclose wherein obtaining the performance data comprises a limit on a number of network hops a request can make. However, LI discloses wherein obtaining the performance data comprises a limit on a number of network hops a request can make (LI, paragraph 0028, wherein “The CDN selector application 406 periodically calculates a performance value for each CDN. By comparing adjusted, forecasted, performance values for each CDN, as described below, an optimal CDN is identified. The CDN selector application 406 may also take into consideration the distances to the respective CDNs in terms of number of hops. Closer CDNs are favored over more distant CDNs”).
Therefore, it would have been obvious to one ordinary skill in the art before the effective filing date of the invention to combine LI with Huang to achieve the claimed limitation because this would have provided a way to improve the performance of the system by selecting the CDN closest in distance to the client (see LI, paragraph 0028).
Conclusion
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 HAMZA N ALGIBHAH whose telephone number is (571)270-7212. The examiner can normally be reached 7:30 am - 3:30 pm.
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, Wing Chan can be reached at (571) 272-7493. 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.
/HAMZA N ALGIBHAH/Primary Examiner, Art Unit 2441
Prosecution Insights