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 .
Priority
Receipt is acknowledged of papers submitted under 35 U.S.C. 119(a)-(d), which papers have been placed of record in the file.
Information Disclosure Statement
The information disclosure statement submitted has been considered by the Examiner and made of record in the application file.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 16-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 16 recites the limitation “the smartwatch” in the second clause (“a short-range wireless communication protocol supported by the smartwatch”). There is insufficient antecedent basis for this limitation in the claim. Unlike claims 1 and 11, the preamble of claim 16 does not introduce “a smartwatch.”
Claim 19 recites the limitation “the watch end” (“based on short-range wireless communication between the watch end and the mobile phone end”). There is insufficient antecedent basis for this limitation in the claim, as neither claim 16 nor claim 19 previously introduces “a watch end.” Claim 20 likewise recites “the watch end and the serving end belong to payment applications …” and “make a watch payment through the watch end,” each lacking antecedent basis for “the watch end.”
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 3, 4, 10, 11, 13, 14, 16, 18, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Slevinsky et al. (US 2020/0053519 A1, hereinafter “Slevinsky”) in view of Hoyland et al. (US 7,529,812 B2, hereinafter “Hoyland”).
Consider claim 1, Slevisnky discloses a service processing method … applied to a watch end on the smartwatch (Slevinsky [0007], [0145], [0148]; FIG. 7: application program 724 and data routing service 730 executing on wearable computing device 710; Slevinsky lists “digital wristwatches” among wearable electronic devices ([0005])
Slevinsky [0007]: “… a method of delegating communication from a wearable computing device to a remote network via a host computing device connected to the remote network may be summarized as including: (a.1) receiving, via a data routing service, one or more data messages from an application program executed by the processor of the wearable computing device, the application program interfacing with at least one socket interface; (a.2) encapsulating the one or more data messages using a transport protocol, and (a.3) transmitting the one or more data messages to a host routing service provided by the host computing device for de-encapsulation and delivery to the remote network.”
obtaining Socket communication trigger data; (Slevinsky [0142]-[0143]: client RPC calls for TCP socket operations, e.g., creating, binding, opening, and closing TCP sockets)
Slevinsky [0142]: “Specifically, the client library may provide APIs and functions for creating, binding, opening and closing TCP sockets, as well as performing Domain Name System (DNS) queries and domain name resolution.”
Slevinsky [0143]: “The API of the server library facilitates client remote procedure call (RPC) calls for TCP socket operations, as requested by the clients.”
performing encapsulation by using a short-range wireless communication protocol supported by the [wearable] and based on the Socket communication trigger data, to obtain a first data packet; (Slevinsky [0143], [0206], [0150])
Slevinsky [0143]: “The callbacks and callouts allow data routing service 730 to frame RPC requests and socket data when sending it to host computing device 740 …”
Slevinsky [0206]: “At 956, the data routing service encapsulates the packet in a transport protocol and forwards the encapsulated packet to the wearable computing device personal area network service at 958.”
Slevinsky [0150]: “The general PAN may be, for example, a Bluetooth™ PAN. The low-power PAN may be, for example, a Bluetooth™ LE (BLE) PAN.”
sending the first data packet to a mobile phone end on a smartphone by performing short-range wireless communication with the smartphone, (Slevinsky [0207], [0026]; host routing service 755 on host computing device 740 is the mobile phone end)
Slevinsky [0207]: “At 960, the personal area network service transmits the encapsulated packet to the host computing device, via the personal area network.”
Slevinsky [0026]: “The host computing device may be a smart phone …”
so that the mobile phone end parses the first data packet to obtain the Socket communication trigger data, performs [network] communication with a corresponding serving end [on behalf of the wearable], (Slevinsky [0208], [0210], [0138])
Slevinsky [0208]: “At 962, the personal area network service of the host computing device receives the encapsulated packet. The encapsulated packet is de-encapsulated by the host routing service at 964 and its network destination is determined.”
Slevinsky [0210]: “At 968, the packet is forwarded to a network service, where it is then transmitted via the communications interface to the network and its eventual destination, such as a remote computing device.”
Slevinsky [0138]: “The host computing device 740 can receive these data transmissions and, using the CSL, re-transmit them to the network on behalf of the wearable computing device 710.”
and performs encapsulation by using the short-range wireless communication protocol and based on [reply] data returned by the serving end, to obtain a second data packet; and (Slevinsky [0140], [0197])
Slevinsky [0140]: “Similarly, the host routing service 755 operates to receive “reply” data from network service 785, decode or de-encapsulate the reply data, determine a destination on the personal area network, format or encapsulate the reply data for transmission via the personal area network, and forward the encapsulated reply data to the host PAN service 750 for eventual transmission via the PAN.”
Slevinsky [0197]: “When encapsulating, each packet may be associated with a connection identifier, which can be unique for each discrete socket that is accessing the physical channel.”
receiving the second data packet returned from the mobile phone end by performing short-range wireless communication with the smartphone, and parsing the second data packet to obtain the [response] data. (Slevinsky [0143], [0200])
Slevinsky [0143]: “… and to de-frame command responses and socket data coming from the host computing device 740 before returning it to the client application via the CSL functions.”
Slevinsky [0200]: “At 932, the data routing service de-encapsulates the packet and determines a local destination.”
However, Slevinsky does not explicitly disclose:
mobile phone end performs Socket communication with the serving end based on the Socket communication trigger data, and that the data returned to the watch is Socket communication response data returned by the serving end in response to that socket communication.
In the related field of endeavor, Hoyland discloses a client device that lacks a full network stack and sends socket requests to a host acting as a socket proxy. The host parses each request, creates the socket connection to the server requested by the client (i.e., performs Socket communication based on the socket trigger data), and returns the server’s responses to the client:
Hoyland col. 1, ll. 45-54: “Socket requests by client applications running on the client device are passed over the serial link to the host using the SoS protocol. The host serves as a socket proxy for the client device. In other words, the host parses and processes the client requests, and then uses its own operating system to make the socket connection to the server application that has been requested by the client application. The host sends responses from the server application back to the client device over the serial link using the SoS protocol.”
Hoyland col. 7, ll. 9-13: “When the message from client 22 is a request to open a connection to server application 34, SoS server 56 invokes API 62 in order to request that connection 64 be opened, at a connection request step 78.”
Hoyland col. 7, ll. 20-22: “If host OS 50 is unable to open the desired connection, it informs SoS server 56, which sends a failure message over serial link 26 to client 22, at a failure response step 80.”
Hoyland col. 7, ll. 31-41: “The SoS server strips the unneeded protocol headers from packets that it receives over connection 64 from server application 34, and then encapsulates the payloads in the arguments of packets that it creates in accordance with the SoS protocol described above. … SoS client 44 parses the SoS packets and delivers the contents to client application 48.”
Therefore, it would have been obvious to a person having ordinary skill in the art at a time before the effective filing date of the claimed subject matter to combine Slevinsky’s host routing service, on receiving and de-framing a wearable RPC request for a TCP socket operation and Hoyland’s socket communication setup in order to arrive at the instant recitation to make proxying transparent to the server and wearable and yield predictable results.
Examiner Note: See detailed rejection analysis of independent claim 1 for any remaining independent claim rejections.
Consider claim 11, Slevinsky discloses a service processing device for a smartwatch, applied to a watch end on the smartwatch, wherein the device comprises: at least one processor; and a memory communicatively connected to the at least one processor, wherein the memory stores instructions that can be executed by the at least one processor, and when the instructions are executed by the at least one processor, the service processing device is caused to: obtain Socket communication packet (see [0005;0007;0138;0140;0142-0143;0200;0206-0208); and receive the second data packet returned from the mobile phone end by performing short-range wireless communication with the smartphone, and parse the second data packet to obtain the Socket communication
However, Slevinsky does not explicitly disclose:
mobile phone end performs Socket communication with the serving end based on the Socket communication trigger data, and that the data returned to the watch is Socket communication response data returned by the serving end in response to that socket communication.
In the related field of endeavor, Hoyland discloses a client device that lacks a full network stack and sends socket requests to a host acting as a socket proxy. The host parses each request, creates the socket connection to the server requested by the client (i.e., performs Socket communication based on the socket trigger data), and returns the server’s responses to the client:
Hoyland col. 1, ll. 45-54: “Socket requests by client applications running on the client device are passed over the serial link to the host using the SoS protocol. The host serves as a socket proxy for the client device. In other words, the host parses and processes the client requests, and then uses its own operating system to make the socket connection to the server application that has been requested by the client application. The host sends responses from the server application back to the client device over the serial link using the SoS protocol.”
Hoyland col. 7, ll. 9-13: “When the message from client 22 is a request to open a connection to server application 34, SoS server 56 invokes API 62 in order to request that connection 64 be opened, at a connection request step 78.”
Hoyland col. 7, ll. 20-22: “If host OS 50 is unable to open the desired connection, it informs SoS server 56, which sends a failure message over serial link 26 to client 22, at a failure response step 80.”
Hoyland col. 7, ll. 31-41: “The SoS server strips the unneeded protocol headers from packets that it receives over connection 64 from server application 34, and then encapsulates the payloads in the arguments of packets that it creates in accordance with the SoS protocol described above. … SoS client 44 parses the SoS packets and delivers the contents to client application 48.”
Therefore, it would have been obvious to a person having ordinary skill in the art at a time before the effective filing date of the claimed subject matter to combine Slevinsky’s host routing service, on receiving and de-framing a wearable RPC request for a TCP socket operation and Hoyland’s socket communication setup in order to arrive at the instant recitation to make proxying transparent to the server and wearable and yield predictable results.
Consider claim 16, Slevinsky discloses a non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium stores a computer program, which when executed by a processor causes the processor to: obtain Socket communication communication protocol supported by the smartwatch and based on the Socket communication
However, Slevinsky does not explicitly disclose:
mobile phone end performs Socket communication with the serving end based on the Socket communication trigger data, and that the data returned to the watch is Socket communication response data returned by the serving end in response to that socket communication.
In the related field of endeavor, Hoyland discloses a client device that lacks a full network stack and sends socket requests to a host acting as a socket proxy. The host parses each request, creates the socket connection to the server requested by the client (i.e., performs Socket communication based on the socket trigger data), and returns the server’s responses to the client:
Hoyland col. 1, ll. 45-54: “Socket requests by client applications running on the client device are passed over the serial link to the host using the SoS protocol. The host serves as a socket proxy for the client device. In other words, the host parses and processes the client requests, and then uses its own operating system to make the socket connection to the server application that has been requested by the client application. The host sends responses from the server application back to the client device over the serial link using the SoS protocol.”
Hoyland col. 7, ll. 9-13: “When the message from client 22 is a request to open a connection to server application 34, SoS server 56 invokes API 62 in order to request that connection 64 be opened, at a connection request step 78.”
Hoyland col. 7, ll. 20-22: “If host OS 50 is unable to open the desired connection, it informs SoS server 56, which sends a failure message over serial link 26 to client 22, at a failure response step 80.”
Hoyland col. 7, ll. 31-41: “The SoS server strips the unneeded protocol headers from packets that it receives over connection 64 from server application 34, and then encapsulates the payloads in the arguments of packets that it creates in accordance with the SoS protocol described above. … SoS client 44 parses the SoS packets and delivers the contents to client application 48.”
Therefore, it would have been obvious to a person having ordinary skill in the art at a time before the effective filing date of the claimed subject matter to combine Slevinsky’s host routing service, on receiving and de-framing a wearable RPC request for a TCP socket operation and Hoyland’s socket communication setup in order to arrive at the instant recitation to make proxying transparent to the server and wearable and yield predictable results.
Consider claim 3 as applied to respective claim, Slevinsky as modified by Hoyland discloses the limitations of claims 1, 11, and 16, respectively. Hoyland further discloses encapsulating the Socket communication trigger data into packets to obtain a plurality of first data packets, so that after obtaining the plurality of first data packets, the mobile phone end correspondingly assembles and parses the packets to obtain the Socket communication trigger data:
Hoyland col. 6, ll. 1-3: “Segment number—When a message exceeds the maximum packet length (255 bytes), it may be segmented into multiple fragments, indicated by the segment number.”
Hoyland col. 6, ll. 17-19: “… a running, 7-bit packet sequence number, plus a segmentation bit indicating whether the current packet is the final segment in the message, or further segments are to follow.”
Hoyland col. 7, ll. 2-5: “Upon receiving a data packet, SoS server 56 parses the fields in the packet, in accordance with the packet structure described above, at a packet parsing step 76.”
Consider claim 4 as applied to respective claim, Slevinsky further discloses after a specified watch proxy connection between the mobile phone end and the serving end is established, receiving … information that is sent by the mobile phone end and that is actively pushed by the serving end through the watch proxy connection, wherein the watch proxy connection is triggered to be established based on short-range wireless communication between the watch end and the mobile phone end:
– Connection triggered over the short-range link: sockets opened by the wearable’s application over the PAN have their other endpoint on the host (Slevinsky [0149]), in response to the wearable’s RPC calls for opening TCP sockets (Slevinsky [0142]-[0143]).
Slevinsky [0149]: “HDCE 755 a may implement a corresponding socket interface, enabling sockets opened by an application program 724 or proxy service 726 of wearable computing device 710 to have endpoints on wearable computing device 710 and host computing device 740.”
– Server-originated data relayed to the wearable: data arriving at the host from the network and destined for the wearable is encapsulated per socket and delivered over the PAN (Slevinsky FIG. 9A).
Slevinsky [0195]-[0196]: “At 910, the host computing device receives a data packet from the network and forwards the data to the host routing service. … At 912, the host routing service analyzes the data packet and determines that the destination of the packet is the wearable computing device.”
Slevinsky [0198]: “At 916, the host routing service transmits the encapsulated packet to the host personal area network service, which transmits the encapsulated packet to a counterpart service of the wearable computing device via the personal area network.”
Consider claim 10 as applied to respective claim, Slevinsky further discloseswherein the short-range wireless communication protocol is a Bluetooth protocol or a Bluetooth low energy protocol: “The general PAN may be, for example, a Bluetooth PAN. The low-power PAN may be, for example, a Bluetooth™ LE (BLE) PAN” (Slevinsky [0150]; see also Slevinsky [0071], [0081]).
Consider claim 13 as applied to respective claim, Slevinsky further disclosesthe service processing device being caused to perform the encapsulation based on the Socket communication trigger data, to obtain a first data packet specifically comprises being caused to: encapsulate the Socket communication trigger data into packets to obtain a plurality of first data packets, so that after obtaining the plurality of first data packets, the mobile phone end correspondingly assembles and parses the packets to obtain the Socket communication trigger data (see claim 3 above).
Consider claim 14 as applied to respective claim, Slevinsky further disclosesthe service processing device further comprises being caused to: after a specified watch proxy connection between the mobile phone end and the serving end is established, receive, by performing short-range wireless communication with the smartphone, information that is sent by the mobile phone end and that is actively pushed by the serving end through the watch proxy connection, wherein the watch proxy connection is triggered to be established based on short-range wireless communication between the watch end and the mobile phone end (see claim 4 above).
Consider claim 18 as applied to respective claim, Slevinsky further disclosesthe processor being caused to perform the encapsulation based on the Socket communication trigger data, to obtain a first data packet specifically comprises being caused to: encapsulate the Socket communication trigger data into packets to obtain a plurality of first data packets, so that after obtaining the plurality of first data packets, the mobile phone end correspondingly assembles and parses the packets to obtain the Socket communication trigger data (see claim 3 above).
Consider claim 19 as applied to respective claim, Slevinsky further disclosesthe processor further comprises being caused to: after a specified watch proxy connection between the mobile phone end and the serving end is established, receive, by performing short-range wireless communication with the smartphone, information that is sent by the mobile phone end and that is actively pushed by the serving end through the watch proxy connection, wherein the watch proxy connection is triggered to be established based on short-range wireless communication between the watch end and the mobile phone end (see claim 4 above).
Allowable Subject Matter
Claims 2, 5-9, 12, and 15 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.
The following is a statement of reasons for the indication of allowable subject matter: See respective recitations.
Claims 17 and 20 are allowable over prior art, however, other outstanding issues remain.
Conclusion
Any response to this Office Action should be faxed to (571) 273-8300 or mailed to:
Commissioner for Patents
P.O. Box 1450
Alexandria, VA 22313-1450
Hand-delivered responses should be brought to
Customer Service Window
Randolph Building
401 Dulany Street
Alexandria, VA 22314
Any inquiry concerning this communication or earlier communications from the
Examiner should be directed to Fayyaz Alam whose telephone number is (571) 270-1102. The Examiner can normally be reached on Monday-Friday from 9:30am to 7:00pm.
If attempts to reach the Examiner by telephone are unsuccessful, the Examiner’s supervisor, Jeanette Parker can be reached on (571) 270-3647. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free) or 703-305-3028.
Any inquiry of a general nature or relating to the status of this application or proceeding should be directed to the receptionist/customer service whose telephone number is (571) 272-2600.
Fayyaz Alam
September 24, 2026
/FAYYAZ ALAM/
Primary Examiner, Art Unit 2646
