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 .
Response to Arguments
Regarding applicant’s arguments directed at the 35 U.S.C. 101 rejection, examiner respectfully disagrees:
Applicant argues that the claims do not recite an abstract idea. Examiner respectfully disagrees and points to the previous office action. The claims recite a mental observation, evaluation, judgment, and opinion, alongside extra solution activity. Examiner would like to point to a recent decision from United States Court of Appeals for the Federal Circuit Trinity Info Media, LLC v. Covalent, Inc., (Fed. Cir. 2023). This decision is relevant because the court held that collecting information “including when limited to a particular content”, performing an analysis that can be performed mentally or a comparison or using a mathematical technique, then reporting the result “is all abstract”. See page 9 of the decision.
Applicant also argues that the invention cannot be practically performed in the human mind as it relates to machine to machine communication. Again examiner disagrees as the case above, recently decided, teaches “The ’685 patent’s requirements that the abstract idea be performed on a “hand-held device” or that matches are “reviewable by swiping” does not alter our conclusion that the focus of the asserted claims remains directed to an abstract idea. See, e.g., In re TLI Commc’ns LLC Pat. Litig., 823 F.3d 607, 613 (Fed. Cir. 2016) (“[A]lthough the claims limit the abstract idea to a particular environment—a mobile telephone system—that does not make the claims any less abstract for the step 1 analysis.”). Nor are we persuaded that dependent claim 8 of the ’321 patent—further requiring processors configured to perform operations with web servers, a database, and a match aggregator—changes the focus of the asserted claims. See id.; see also ChargePoint, 920 F.3d at 766–67, 770 (adding networking capabilities to facilitate network communication did not prevent the claim from being directed to an abstract idea);” See page 10. Therefore the applicants arguments that the amended recitation of network elements DOES NOT prevent the claim from being directed to an abstract idea.
In this current application we have collecting information (the request and the label retrieval) then making a mental determination (return info if X being the condition) and reporting the data (transmitting the result). These claims are directed towards an abstract idea.
Applicant further argues that claims are an improved and unique approach to retrieving resource information:
Examiner respectfully disagrees. The claims center around a mental determination that is abstract in nature. Furthermore examiner points to the recent case law above which clearly indicates, the application of an abstract idea to a technical field is not sufficient to transform the claim.
Regarding applicant’s arguments directed at the amended claim limitations of claim 1:
Applicant argues on page 16-17 that Ly does not return a label, examiner respectfully disagrees:
First, the applicant does not define a label. Nothing in the claims prevents a list of links directed at a specific interworking technology from being interpreted as labels. Both are strings, both represent a specific interworking technology. Furthermore the applicant argues the use of a plurality of different standards. Examiner respectfully notes that this is absent from the claims and cannot be read into the claims.
Second, in the cited sections 230-233 Ly recites does recite that a link is provided, examiner points to 0214 which teaches that the links include interworking attributes:
In step 8, optionally rd01 may also create a new interface for cse01 where RD endpoints may target to search for resources in cse01. The new RD interface may have the form “/rd-iw/cse01” or “/rd/iw-cse01” and RD endpoints may target this new interface to search for resources on cse01. A new link format attribute “Interworking Resource Type” (iwrt) may be introduced that maps to oneM2M's labels attribute. Alternatively, a new RD endpoint registration entry for cse01 may be added to the RD with a new link format attribute “Interworking Type” (iwt) to indicate interworking is available. RD endpoints may target the newly created cse01 registration with the iwt attribute to initiate a resource discovery on cse01. The RD endpoint may provide the iwrt attribute to search for resources in cse01.
Applicant argues that system does not selectively and restrictively return a result based on the type of the application entity:
Examiner would first like to note that [0041] of Ly incorporates the technical standard, which was ignored in the response for its supporting features:
The oneM2M TS teaches access control for returned information based on if the AE has permission or not, we have interpreted this to be the application type (1 type has permission and the other type does not).
Examiner notes that the oneM2M Technical Standard TS-0001-V1.13.1 teaches the following
(1) a oneM2M request message directed at resources information must include the sender information (see page 59) showing From identifier as mandatory for retrieval request;
(2) When the retrieval request is received the Receiver checks if the originator has appropriate privileges to retrieve information received in the resource OR attribute which are labels (See page 153) https://www.onem2m.org/images/files/deliverables/TS-0001-Functional_Architecture-V1_13_1.pdf;
(3) The TS further teaches (Pages 31, 5-61, 89-90, and 170; as well as all sections discussing interworking) The TS teaches requests and responses used in discovery; Which is in line with Ly’s discovery teachings.
(4) The filtering criteria for discovery used to make match resources, and includes labels, attributes and could be combined with AND/OR modifiers; Originators will be checked to determine they have such access;
(5) If there is a label match, and the originator has access, provide the originator with the labels.
(6) Remembering that there can be multiple requested labels and attributes with AND/OR modifiers; Therefore, the TS spec teaches generating a discovery response, based on a list of labels and attributes, and if there are matches to the requests, determining if they have access, and if so, provide the response.
Therefore the system returns interworking labels to the originator, if the originator type = has access rights. Since there is a condition, it is equal to “selectively and restrictively” based on the type (has permission or not). Applicant is encouraged to amend around the interpretation.
Claim Interpretation
Regarding claim 1, the claim recites “such that a service error caused by provision of unnecessary information is prevented and information security is strengthened” is a statement of intended result or purpose, rather than a structural or functional step. This language describes why the preceding steps are performed (the intended beneficial outcomes), not how they are performed or what specific technical means are used. According to patent law principles and case law (e.g., In re Swinehart, In re Pearson), purely functional or result-oriented language that does not recite structure or concrete steps generally does not impart patentable weight on its own. Examiner respectfully points to MPEP Section 2111.04 “Claim scope is not limited by claim language that suggests or makes optional but does not require steps to be performed, or by claim language that does not limit a claim to a particular structure. However, examples of claim language, although not exhaustive, that may raise a question as to the limiting effect of the language in a claim are:
(A) "adapted to" or "adapted for" clauses;
(B) "wherein" clauses; and
(C) "whereby" clauses.”
Furthermore, the section discusses when the clause gives meaning and purpose to the manipulative steps, but further emphasize “However, the court noted that a "‘whereby clause in a method claim is not given weight when it simply expresses the intended result of a process step positively recited.’" Id. (quoting Minton v. Nat’l Ass’n of Securities Dealers, Inc., 336 F.3d 1373, 1381, 67 USPQ2d 1614, 1620 (Fed. Cir. 2003)).”
Examiner interprets the limitation recited above to be simply expressing the intended result of a process step that is positively recited “transmitting” and therefore will not be given weight.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-2, 5-13, and 16-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to mental/pen and paper step of selectively filtering without significantly more.
The claim(s) recite(s):
Are the claims directed to a statutory category? Yes, methods and systems.
Are the claims directed to a law of nature, a natural phenomenon, or an abstract idea?
Regarding claim 1, the claim recites steps of (1) receiving a request by an M2M system (Examiner notes transmitting and receiving information is part of data gathering and is considered to be insignificant extra solution activity that does not add significantly more to the abstract idea to render the claimed invention patentable See MPEP § 2106.05(g); Revised Guidance 55, n.31; see In re Bilski, 545 F.3d 943, 962 (Fed. Cir. 2008) (en bane), aff'd on other grounds, 561 U.S. 593 (2010) ("[T]he involvement of the machine or transformation in the claimed process must not merely be insignificant extra-solution activity") The oneM2M system is implemented using generic hardware see Fig 8)
(2) retrieving information (interpretation of element 1 above)
(3) obtaining a response based on a determination (mental step) on if a condition is met (Examiner notes that the determination is the selectively filtering step which is the abstract idea and "an observation, evaluation, judgment, opinion" which could be performed as a mental process. See MPEP § 2106.04(a)(2)(III)(A). The determination is made by matching information and therefore part of the abstract idea. The step of generating a response for transmission is part of the data gathering and transmission which is considered extra solution activity)
(4) Identifying information that was received, examiner respectfully notes identifying information is part of a mental determination as it is merely recognizing information and therefore part of the abstract idea and is considered extra solution activity. The MPEP is clear on mental determinations "an observation, evaluation, judgment, opinion" which could be performed as a mental process. See MPEP § 2106.04(a)(2)(III)(A). The human brain identifies information using evaluations and observations, in this case identifying consists of observing the information receiving and making an evaluation.
(5) In a case return information, examiner further notes again that this is a Boolean logic yes or no and therefore part of the mental determination step and therefore part of the abstract idea. Furthermore examiner notes that this mental determination is part of two “in case” covering both returns of yes, and no, and therefore both are covered under a mental determination. . The MPEP is clear on mental determinations "an observation, evaluation, judgment, opinion" which could be performed as a mental process. See MPEP § 2106.04(a)(2)(III)(A). In this case “in case” is a mental judgement or evaluation and therefore part of the abstract idea.
(6) and communicating the information based on the determination above. (See interpretation above)
(7) Such that a service error caused by provisioning unnecessary information is presented and information security is strengthened. Examiner notes that claim is actually doing the exact opposite, it runs similar to any search engine, and if no input is provided then it returns all the information, weakening information security and provisioning unnecessary information.
Examiner notes that deciding to return information based on a condition is BY DEFINITION “selective” and “restrictive”. Furthermore the specification provides no definition for either. Examiner also notes the claims don’t actively recite the determination, but merely using the result.
Claims 2-9 are all directed at making some determination, “in case that” limitations directed at “if x information send y” and attempting to cover as many different at times contradicting variations as possible, which is the focus of the claims and IS the abstract idea. Claims 10-20 inherit the same interpretation for reciting similar limitations.
In Data Engine Technologies LLC v. Google LLC (Fed. Cir 2018) The courts determined Claim 12 of the ‘259 patent to be patent eligible because it provided limitations directed at the specific technical solution and concluded that the invention therein was "directed to a specific method for navigating through three-dimensional electronic spreadsheets" rather than an abstract idea. The courts further determined that a broad version of the claim, Claim 1 of the ‘551 patent was patent ineligible and was struck down under 35 U.S.C. 101 as the court determined the claim "generically recites associating each of the cell matrices with a user-settable page identifier and does not recite the specific implementation of a notebook tab interface." And further stated "not limited to the specific technical solution and improvement in electronic spreadsheet functionality that rendered representative claim 12 of the '259 patent eligible . . . [i]nstead, claim 1 . . . covers any means for identifying electronic spreadsheet pages.". For the same reasoning and rationale, the examiner is of the opinion that the claim is directed at an abstract idea.
This judicial exception is not integrated into a practical application because the claims are directed to selectively filtering based on a determination. The claims are clearly directed and focused on the determination which is a mental step. In its analysis, the Federal Circuit enquired whether "the claims are directed to a specific improvement in the capabilities of computing devices, or, instead, 'a process that qualifies as an "abstract idea" for which computers are invoked merely as a tool."' Core Wireless Licensing S.A.R.L. v. LG Electronics, Inc., 880 F.3d 1356, 1361-62 (Fed. Cir. 2018) (quoting Enfish, LLC v. Microsoft Corp., 822 F.3d 1327, 1336 (Fed. Cir. 2016).
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the elements of M2M covers all and any machine communication and therefore deemed to be extra solution activity. Furthermore the claims lack to add specific limitations beyond the judicial exception that are not "well-understood, routine, conventional" in the field. Furthermore the claims simply append well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-2, 5-13, and 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.
Regarding claim 1, the claim recites “such that a service error caused by provision of unnecessary information is prevented and information security is strengthened.” Examiner respectfully notes that the claim limitation directly preceding the “such that” limitation recites “and in case that the interworking technology is not specified, transmitting, by the M2Msystem, all of the retrieved interworking information labels”. Examiner is unclear how a null variable (interworking technology is not specified) resulting in returning of ALL the information is considered to be preventing provisioning of unnecessary information, and strengthening security when it returns all the information as a result of no input, in fact it seems to be reading the exact opposite.
Claims 10-12 inherit the same rejection as claim 1 for reciting similar limitations.
Regarding claim 5, the claim recites “wherein in case that the interworking technology is specified, the transmitting comprises determining to return the interworking information label related to the specified interworking technology along with other normal information labels of the retrieved resources”. Examiner notes a few issues:
The claim recites “the transmitting comprises”, yet the transmitting was already defined in claim 1 and therefore should read “further comprises”.
The claim recites “the transmitting comprises determining to return the interworking information label related to the specified interworking technology along with other normal information labels of the retrieved resources” Examiner points to claim 1 which recites “transmitting, by the M2M system, an interworking information label only related to the specified interworking technology;” recites returning an interworking information label ONLY, yet claim 5 clearly recites returning NOT ONLY the interworking information label, but also other labels.
Claim 16 inherits the same rejection for reciting similar limitations.
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.
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.
Claim(s) 1-2, 5, 7-13, 16, and 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ly et al. (US 20210211509 A1) in view of Applicant admitted prior art Current Specification hereinafter AAPA.
Regarding claim 1, Ly teaches a processor-implemented (0302; processor) method of retrieving resource information, performed in a machine-to-machine (M2M) (0041; M2M) communication network using plural different standards (0003; different protocols; 0041; different standards), the method comprising: (0059; method)
communicating, by an M2M system (Fig 35; M2M system) via the M2M communication network (Fig 35 ; M2M communication network), with an application entity (AE),(Fig 22; OneM2M AE) by receiving a label retrieval request (Fig 22; 10. Resource discovery Get request; Fig 23; [0230] the oneM2M AE transmits a discovery request with interworking attributes and is received by the oneM2M CSE), regarding a resource (resources hosted on devices) from the application entity (AE) requesting the label retrieval request (see previous mapping) via the M2M communication network (Fig 35); (discovery request with filter criteria as interworking attribute which is the label); (0227; In step 10, a oneM2M AE may perform resource discovery using filter criteria of resources hosted by an RD by specifying iwType=RD. Using the filter criteria in this way informs the hosting CSE that the AE is only interested in discovering resources of RD endpoints. 0214; A new link format attribute “Interworking Resource Type” (iwrt) may be introduced that maps to oneM2M's labels attribute. 0076; Devices will either discover the Interworking Service using their native discovery request or be provisioned with information about the Interworking Service. They then send requests in their native protocol to the Interworking Service, which then translates the request to an entity operating with a different SL protocol. 0077; The Interworking Service may be integrated in an IoT server, such as a oneM2M Common Services Entity (CSE) or a CoRE Resource Directory (RD) server )
retrieving, by the M2M system, labels of resources; ; (Figs 22-23; 0227-0228; In step 11, cse01 searches its resource tree and finds res1 and res2 flexContainers. In step 12, cse01 returns the search result to the AE.; See mapping above where the resources returned are based on interworking attribute label; 0230; In Step 2, a oneM2M AE performs resource discovery in which the attributes iwType and iwCapabilities are utilized to inform the CSE that the AE is looking to find devices with capability of light that is listed in an RD.; 0233; In Step 8, the Interworking Service interworks the response from rd01 to a response to cse01. In Step 9, the Interworking Service sends a response to cse01 with the results of the RD lookup query. In Step 10, cse01 returns a list of URIs that correspond to the link formats found from the RD lookup interface. )
obtaining, (Fig 23 interworking response message) by the M2M system, a label retrieval result, associated with the label retrieval request, (discovery iwType and iwCapabilities), based on a result of determining whether to return (requesting application has access privileges) an interworking information label on which information (interworking label) regarding data interworking with another system is recorded, among the retrieved labels of the resources, (Fig. 23; examiner respectfully notes interworking is by definition connecting of different networks, under BRI the different network can be another system, for this interpretation examiner interprets the “another system” as another network and therefore is inherent in the definition of interworking)
selectively and restrictively (returning interworking information if condition of requesting entity permissions are met by definition is “selective” and “restrictive”) based on a type (types being equivalent to has appropriate privileges or not) of the application entity (AE) (oneM2M AE); (0227-0233; Figs 22-23; Examiner notes that the discovery is for iw attributes which are interworking attributes, interworking is by definition working between systems or devices; and then based on the search returns resources with interworking labels; Examiner notes 0041 incorporates the technical standards for oneM2M and oneM2M Technical Standard TS-0001-V1.13.1 teaches the following (1) a oneM2M request message directed at resources information must include the sender information (see page 59) showing From identifier as mandatory for retrieval request; (2) When the retrieval request is received the Receiver checks if the originator has appropriate privileges to retrieve information received in the resource OR attribute which are labels (See page 153) https://www.onem2m.org/images/files/deliverables/TS-0001-Functional_Architecture-V1_13_1.pdf; The TS further teaches (Pages 31, 5-61, 89-90, and 170; as well as all sections discussing interworking) The TS teaches requests and responses used in discovery; The filtering criteria for discovery used to make match resources, and includes labels, attributes and could be combined with AND/OR modifiers; Originators will be checked to determine they have such access; If there is a label match, and the user has access, provide the user with the labels. Remembering that there can be multiple requested labels and attributes with AND/OR modifiers; Therefore, the TS spec teaches generating a discovery response, based on a list of labels and attributes, and if there are matches to the requests, determining if they have access, and if so, provide the response))
and communicating, by the M2M system (mapping above and see Figs 17-35), via the M2M communication network, (mapping above and see Figs 17-35) with the application entity (AE), by returning the label retrieval result, ((Figs 22-23; 0227-0228; In step 11, cse01 searches its resource tree and finds res1 and res2 flexContainers. In step 12, cse01 returns the search result to the AE.; See mapping above where the resources returned are based on interworking attribute label; 0233; In Step 8, the Interworking Service interworks the response from rd01 to a response to cse01. In Step 9, the Interworking Service sends a response to cse01 with the results of the RD lookup query. In Step 10, cse01 returns a list of URIs that correspond to the link formats found from the RD lookup interface of resources with labels) including a label of a resource retrieved selectively and restrictively according to a result of the determining, (Examiner respectfully notes the retrieval of interworking information of a resource that was returned based on access privileges is mapped above and therefore omitted here)
determining, further including:
identifying, by the M2M system, interworking technology specified on information of the AE; (Fig 23; 0214-0215; 0228; 0230-0233; Fig 23 shows an AE request including interworking attributes (equivalent to specified information of the AE))
in case that the interworking technology is specified, transmitting, by the M2M system, an interworking information label only related to the specified interworking technology; (Examiner respectfully notes that Ly does not recite that the non-requested interworking attributes are returned but the requested attributes are returned and therefore is equivalent to “only related”; mapping above + Fig 23; 0230-0233; Based on the request the system returns resources with the interworking attribute (equivalent to label related to the specified interworking technology))
such that a service error caused by provision of unnecessary information is prevented and information security is strengthened. (Examiner respectfully notes this limitation will not be mapped as it recites the intended result of a step positively recited and points to MPEP Section 2111.04 which teaches “However, the court noted that a "‘whereby clause in a method claim is not given weight when it simply expresses the intended result of a process step positively recited.’" Id. (quoting Minton v. Nat’l Ass’n of Securities Dealers, Inc., 336 F.3d 1373, 1381, 67 USPQ2d 1614, 1620 (Fed. Cir. 2003)).” According to patent law principles and case law (e.g., In re Swinehart, In re Pearson), purely functional or result-oriented language that does not recite structure or concrete steps generally does not impart patentable weight on its own. Furthermore, examiner notes that such that is reciting an intended result, therefore it would logically flow that because Ly recites the above steps it is inherent that it can yield the same intended result)
Ly does not explicitly teach and in case that the interworking technology is not specified, transmitting, by the M2M system, all of the retrieved interworking information labels.
In an analogous art, AAPA discloses in case that the interworking technology is not specified, transmitting, by the M2M system, all of the retrieved interworking information labels (Fig 2 and 0007; teach all of the labels including interworking labels are returned when interworking technology or attribute is not specified in the retrieval request)
It would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to modify the teachings of Ly to include returning interworked and regular labels as is taught by the applicant admitted prior art
The suggestion/motivation is to improve oneM2M systems
Regarding claim 2, Ly in view of AAPA teach the method of claim 1, wherein the determining comprises:
identifying, by the M2M system, the type of sent the label retrieval request; (Mapping above in claim 1 for label retrieval; Figs 23-25 and 28, 0027-0028; The request is coming from a oneM2M AE)
and in case that the identified type is an interworking proxy application entity (IPE) type, (0203; Interworking service is an enhanced oneM2M IPE) determining, by the M2M system, to transmit an interworking information label. (Mapping above in claim 1; Table 10 and Table 11; Fig 30 Step 6; HTTP search result of resources based on filterCriteria). (0203; Interworking attributes include iwType, iwCapabilities, and iwInterfaces. 0262-0264; The interworking service (IPE) requests a search of resources with a label criteria from the oneM2M (see Fig 30 Step 5) and receives search results which include resources with the filtered label which as mapped above are interworking attributes and equivalent to interworking information label; Examiner respectfully points to claim 1 above showing how the technical standard teaches determining to return attributes based on the originator having privileges)
Regarding claim 5, Ly in view of AAPA teaches the method of claim 1, and is disclosed above, Ly does not explicitly teach but AAPA teaches wherein in case that the interworking technology is specified, the transmitting comprises determining to return the interworking information label related to the specified interworking technology along with other normal information labels of the retrieved resources, (Examiner notes this is an alternative limitation as the interworking information label cannot both be specified and not specified simultaneously, examiner does not elect this limitation)
and wherein in case that the interworking technology is not specified, the transmitting comprises determining to return the interworking information labels along with other normal information labels retrieved. (Fig 2 and 0007; teach all of the labels including interworking labels are returned when interworking technology or attribute is not specified in the retrieval request)
It would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to modify the teachings of Ly to include returning interworked and regular labels as is taught by the applicant admitted prior art
The suggestion/motivation is to improve oneM2M systems
Regarding claim 7, Ly in view of AAPA teach the method of claim 1, and is disclosed above, Ly further teaches wherein the
identifying, by the M2M system, a retrieval attribute of the retrieval request; (0227; In step 10, a oneM2M AE may perform resource discovery using filter criteria of resources hosted by an RD by specifying iwType=RD. Using the filter criteria in this way informs the hosting CSE that the AE is only interested in discovering resources of RD endpoints. 0214; A new link format attribute “Interworking Resource Type” (iwrt) may be introduced that maps to oneM2M's labels attribute. 0076; Devices will either discover the Interworking Service using their native discovery request or be provisioned with information about the Interworking Service. They then send requests in their native protocol to the Interworking Service, which then translates the request to an entity operating with a different SL protocol. 0077; The Interworking Service may be integrated in an IoT server, such as a oneM2M Common Services Entity (CSE) or a CoRE Resource Directory (RD) server )
and in case that the identified retrieval attribute indicates interworking information retrieval, determining, by the M2M system, to transmit the interworking information label. (Figs 22-23; 0227-0228; In step 11, cse01 searches its resource tree and finds res1 and res2 flexContainers. In step 12, cse01 returns the search result to the AE.; See mapping above where the resources returned are based on interworking attribute label; 0230; In Step 2, a oneM2M AE performs resource discovery in which the attributes iwType and iwCapabilities are utilized to inform the CSE that the AE is looking to find devices with capability of light that is listed in an RD.; 0233; In Step 8, the Interworking Service interworks the response from rd01 to a response to cse01. In Step 9, the Interworking Service sends a response to cse01 with the results of the RD lookup query. In Step 10, cse01 returns a list of URIs that correspond to the link formats found from the RD lookup interface. )
Regarding claim 8, Ly in view of AAPA teach the method of claim 7, and is disclosed above, Ly further teaches wherein in case that the identified retrieval attribute indicates interworking information retrieval, (Figs 22-23; 0227-0228; In step 11, cse01 searches its resource tree and finds res1 and res2 flexContainers. In step 12, cse01 returns the search result to the AE.; See mapping above where the resources returned are based on interworking attribute label; 0230; In Step 2, a oneM2M AE performs resource discovery in which the attributes iwType and iwCapabilities are utilized to inform the CSE that the AE is looking to find devices with capability of light that is listed in an RD.; 0233; In Step 8, the Interworking Service interworks the response from rd01 to a response to cse01. In Step 9, the Interworking Service sends a response to cse01 with the results of the RD lookup query. In Step 10, cse01 returns a list of URIs that correspond to the link formats found from the RD lookup interface. )
Ly does not explicitly teach the transmitting comprises determining to transmit the interworking information label along with other normal information labels retrieved.
Examiner respectfully points to AAPA which teaches the transmitting comprises determining to transmit the interworking information label along with other normal information labels retrieved (Fig 2 and 0007; Clearly indicated as Prior art discloses regular attributes and interworking attributes being returned at the same time)
It would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to modify the teachings of Ly to include returning interworked and regular labels as is taught by the applicant admitted prior art
The suggestion/motivation is to improve oneM2M systems
Regarding claim 9, Ly in view of AAPA teach the method of claim 7, and is disclosed above further teaches wherein in case that the identified retrieval attribute indicates normal information retrieval, determining, by the M2M system, to return only a normal information label except for the interworking information label (AAPA: Fig 2 and 0007; teach all of the labels including interworking labels are returned when interworking technology or attribute is not specified in the retrieval request)
Regarding claim 10, the claim inherits the same rejection as claim 1 above for reciting similar limitations in the form of a system claim. (Figs 22-23; 0227; AE making the request; 0301; Computer system)
Regarding claim 11, the claim inherits the same rejection as claim 1 above for reciting similar limitations in the form of a method claim. ((0059; method; Figs 22-23; 0227; AE making the request; 0301; Computer system)
Regarding claim 12, the claim inherits the same rejection as claim 1 above for reciting similar limitations in the form of a system claim. (Figs 22-23; 0227; AE making the request; 0301; Computer system)
Regarding claim 13, the claim inherits the same rejection as claim 2 above for reciting similar limitations in the form of a system claim. (Figs 22-23; 0227; AE making the request; 0301; Computer system)
Regarding claim 16, the claim inherits the same rejection as claim 5 above for reciting similar limitations in the form of a system claim. (Figs 22-23; 0227; AE making the request; 0301; Computer system)
Regarding claim 18, the claim inherits the same rejection as claim 7 above for reciting similar limitations in the form of a system claim. (Figs 22-23; 0227; AE making the request; 0301; Computer system)
Regarding claim 19, the claim inherits the same rejection as claim 8 above for reciting similar limitations in the form of a system claim. (Figs 22-23; 0227; AE making the request; 0301; Computer system)
Regarding claim 20, the claim inherits the same rejection as claim 9 above for reciting similar limitations in the form of a system claim. (Figs 22-23; 0227; AE making the request; 0301; Computer system)
Claim(s) 6 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ly et al. (US 20210211509 A1) in view of Applicant admitted prior art Current Specification hereinafter AAPA in view of Wang et al. (US 20220141309 A1).
Regarding claim 6, Ly in view of AAPA teach the method of claim 1, and is disclosed above, Ly further teaches wherein the
identifying, by the M2M system, the type of the application entity (AE) which sent the label retrieval request; and(Mapping above in claim 1 for label retrieval; Figs 23-25 and 28, 0027-0028; The request is coming from a oneM2M AE) (0203; Interworking service is an enhanced oneM2M IPE) (Mapping above in claim 1; Table 10 and Table 11; Fig 30 Step 6; HTTP search result of resources based on filterCriteria). (0203; Interworking attributes include iwType, iwCapabilities, and iwInterfaces. 0262-0264; The interworking service (IPE) requests a search of resources with a label criteria from the oneM2M (see Fig 30 Step 5) and receives search results which include resources with the filtered label which as mapped above are interworking attributes and equivalent to interworking information label; Examiner respectfully points to claim 1 above showing how the technical standard teaches determining to return attributes based on the originator having privileges)
Ly in view of AAPA do not explicitly teach in case that the identified type is a normal type different from an interworking proxy application entity (IPE) type, determining, by the M2M system, to return only a normal information label except for the interworking information label.
In an analogous art Wang teaches in case that the identified type is a normal type(Table 7 0136; Fig. 6; 0061-0065; requesting application/originator is determined if they have the privileges to retrieve the information (equivalent to normal type)) different from an interworking proxy application entity (IPE) type,(the originator is not a proxy and therefore this is inherent) determining, by the M2M system, to return only a normal information label except for the interworking information label. (The originator can flexibly request different attributes and therefore can request “normal” information and get it returned therefore it excludes any interworking information 0057; and Table 1; Fig 28 0118-0119; Table 7 and 0153; where the representation of the retrieved <contentInstance> including its attributes may be transmitted from the server to the application. The AE can request attributes for resources, and receive attributes of resource; 0079-0081; Then, the originator may process the recovered response message to get the resource representation of the target resource, which may be the combination of each RRCP as indicated in the response message plus any additional attributes contained in the response message.))
It would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to modify the teachings of Ly in view of AAPA to include receiving resources and their information that do not include interworking information as is taught by Wang
The suggestion/motivation is to improve oneM2M systems [0001-0008]
Regarding claim 17, the claim inherits the same rejection as claim 6 above for reciting similar limitations in the form of a system claim. (Figs 22-23; 0227; AE making the request; 0301; Computer system)
Conclusion
THIS ACTION IS MADE FINAL. 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 ABDERRAHMEN H CHOUAT whose telephone number is (571)431-0695. The examiner can normally be reached on Mon-Fri from 9AM to 5PM PST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christopher Parry, can be reached at telephone number 571-272-8328. 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.
Examiner interviews are available via a variety of formats. See MPEP § 713.01. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/InterviewPractice.
Abderrahmen Chouat
Examiner
Art Unit 2451
/Chris Parry/Supervisory Patent Examiner, Art Unit 2451